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Abstract 



In this thesis, the synthesis of correct-by-construction controhers for robots as- 
sisting in Search and Rescue (SAR) is considered. In recent years, the develop- 
ment of robots assisting in disaster mitigation in urban environments has been 
actively encouraged, since robots can be deployed in dangerous and hazardous 
areas where human SAR operations would not be possible. 

In order to meet the reliability requirements in SAR, the specifications of the 
robots are stated in Linear Temporal Logic and synthesized into finite state ma- 
chines that can be executed as controllers. The resulting controllers are purely 
discrete and maintain an ongoing interaction with their environment by chang- 
ing their internal state according to the inputs they receive from sensors or other 
robots. 

Since SAR robots have to cooperate in order to complete the required tasks, 
the synthesis of controllers that together achieve a common goal is considered. 
This distributed synthesis problem is provably undecidable, hence it cannot be 
solved in full generality, but a set of design principles is introduced in order to 
develop specialized synthesizable specifications. In particular, communication 
and cooperation are resolved by introducing a verified standardized communi- 
cation protocol and preempting negotiations between robots. 

The robots move on a graph on which we consider the search for stationary and 
moving targets. Searching for moving targets is cast into a game of cops and 
robbers, and specifications implementing a winning strategy are developed so 
that the number of robots required is minimized. 

The viability of the methods is demonstrated by synthesizing controllers for 
robots performing search and rescue for stationary targets and searching for 
moving targets. It is shown that the controllers are guaranteed to achieve the 
common goal of finding and rescuing the targets. 
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Chapter 1 

Introduction 



Robot-assisted Search and Rescue (SAR) has received increased pubhc attention 
after the 1995 Hanshin-Awaji Earthquake in Kobe, Japan, and the attacks in 
the same year on the Murrah Federal Building in Oklahoma City, USA 80i : The 
RoboCup- Rescue project, started in 1998 at several Japanese universities is one 
of the first reactions of robotics researchers to the aforementioned earthquake, 
encouraging the development of robots assisting in disaster mitigation |86] . 

The US Federal Emergency Management Agency gives the following definition: 

Urban search-and-rescue (USAR) involves the location, rescue (ex- 
trication) , and initial medical stabilization of victims trapped in con- 
fined spaces!^ 

A recent survey by Goodrich et al. [JT] extends the application of SAR opera- 
tions from confined urban spaces: 

Wilderness search and rescue (WiSAR) operations include finding 
and providing assistance to humans who are lost or injured in moun- 
tains, deserts, lakes, rivers, or other remote settings. 

Thus, SAR entails searching for people that are in distress or in need of med- 
ical support and providing relief to their situation. In an abstract sense, SAR 
includes the searching of any kind of problematic object and alleviating the sit- 
uation. This requires teams of trained personnel, a well-managed organizational 
structure and management of equipment logistics. 



Motivating Robot- Assisted SAR 

Consider the scenario of a burning building, or the aftermath of a devastating 
hurricane. Usually there is only limited information available about whether 
there were people in the affected area at the time of the incident and what the 
imminent dangers to the rescue personnel are. Deploying SAR teams exposes 
personnel to the dangers of the site, and rescue efforts might be slow and costly. 



^http : //www . f ema . gov/emergency/usr/1 accessed 19 Oct 2011 



Supporting the SAR efforts by robots has several advantages. Robots can be 
deployed in hazardous areas where human operations would not be possible. A 
major issue during disasters is the physical exhaustion and lack of sleep of SAR 
personnel, resulting in an increased susceptibility to misjudgements. Robots 
do not suffer from this kind of fatigue, even though their power supply needs 
regular recharging. Also, the precision of the sensors and speed of robots can 
by far outmatch those of humans. This is usually partially alleviated by canine- 
supported or mounted SAR teams, with the obvious limitations in hazardous 
or physically demanding environments. 

As SAR robots obtain higher levels of autonomy, it can also be expected that 
the number of human operators per robot can be decreased. For each SAR 
robot that was employed during the operations after the September 11 attacks 
on the World Trade Center in 2001, at least two or more operators were needed, 
even though the robots had only very basic reconnaissance capabilities. Current 
examples of autonomous vehicles with greater operational capabilities are de- 
ployed in military applications, and require even a larger number of operators, 
e.g. 180 for the General Atomics Predator (but here the degree of autonomy is 
partially limited due to legal constraints) o 

Automated synthesis for a particular class of specifications can be done effi- 
ciently in polynomial time. This could even allow feasible on-the-fly synthesis 
of controllers if the configuration changes during a field operation, e.g. by at- 
taching a new sensor or by changing the means of locomotion j63| . In this 
case, it is merely required to add the appropriate rules to the specification, as 
highlighted in the discussion of incremental modification at the beginning of 
Section [Sj However, the main limitation of synthesis approach is the large state 
space size of the resulting controllers. Hand-coded controllers are less prone to 
this problem (see the comparisons in Bloem et al. [11), but cannot be scaled to 
arbitrary size and complexity. 



Contributions 

In this thesis, the development of controllers for autonomous SAR robots is 
investigated. In order to act autonomously, a robot must be enabled to make 
decisions about the actions it performs, based on its observations about the 
environment and the other robots. 

We consider purely discrete controllers for SAR robots that maintain an ongoing 
interaction with their environment by changing their internal state according to 
the inputs they receive. The specification of such controllers consists of a set of 
rules or guarantees such as "each location in the search area is visited repeat- 
edly," while allowing assumptions about the environment to be made, such as 
"targets cannot move faster than 3 mph." Such statements are be expressed in 
a formal high-level specification language which closely matches how humans 
would naturally express such properties. 



^The Economist, Drones and the Man, Jul 30th 2011, | http: //www .economist, com/node/ 
[21524876, accessed 28 Oct 2011. 



1.1. ROBOT-ASSISTED SAR SCENARIOS 



Instead of merely verifying properties, we are concerned with synthesizing con- 
trohers that are correct by construction. Using such an approach shifts the 
vahdation effort to the specification. However, expressing the specifications in 
a high-level language can greatly simplify this process. 

SAR is typically performed using several agents that have to coordinate and 
communicate. We therefore need to consider the synthesis of controllers that 
together achieve a common goal. This is called compositional (or distributed) 
synthesis, and is in general undecidable |76j . The compositional synthesis prob- 
lem therefore cannot be solved in its full generality, but we introduce a set of 
design principles that help to develop appropriate specifications that can be 
synthesized. Communication and coordination are resolved by introducing a 
standardized control protocol and preempting negotiations between robots. 

The viability of our methods is demonstrated by synthesizing controllers for 
robots performing search and rescue for stationary targets and searching for 
moving targets. A four-phase handshake protocol is used to communicate com- 
mands between the agents. When interpreting the controllers in real-time, our 
main motivation is not to attain temporal efficiency, but to develop controllers 
that are proven to be reliable. We show that the controllers are guaranteed to 
achieve the common goal of finding and rescuing the targets and provide simu- 
lation results demonstrating the validity of the controllers. 



1.1 Robot- Assisted SAR Scenarios 

In this section, we consider two paradigms for robot-assisted SAR and outline 
the scenarios. The stationary target search in USAR and the moving target 
search in WiSAR guide our development of the specifications that are synthe- 
sized to be executed as controllers on SAR robots. 



1.1.1 USAR 

Robots assisting in USAR can be deployed for a variety of tasks, like inspecting 
damaged or collapsed buildings for imminent danger to human rescuers. Robots 
can also be used to monitor the temperature and air quality in a burning build- 
ing or provide comfort to victims by establishing a two-way audio connection 
to rescue personnel. Casper and Murphy [15, provide a survey of such tasks 
related to the September 11, 2001 attacks on the World Trade Center. 

We study controllers for USAR to develop an understanding of the tasks of 
searching and rescuing when a central coordinating authority exists. In USAR 
we can assume that injured or entrapped persons or objects are not able to 
move. It is therefore sufficient to develop methods for stationary target search, 
which considerably simplifies the controllers. 



1.2. CHALLENGES IN ROBOT-ASSISTED SAR 



1.1.2 WiSAR 

While USAR is mostly concerned with small to medium scale sites such as burn- 
ing or collapsed buildings, WiSAR entails searching over large regions in often 
rugged remote areas [21]. Robot-assisted WiSAR often combines several types 
of Unmanned Air- and Ground Vehicles in order to find a target that might be 
moving in order to get to safety itself. 

The search strategies required for WiSAR are fundamentally different from those 
sufficient for USAR. This is mainly because the targets are assumed to be able 
to move. In this case, the number of robots required for reliable search depends 
on the topology of the environment. Also, the search radius has to increase with 
time, since a target might try to move away from the location at which it is ini- 
tially expected to be, trying to reach safety itself. In this thesis we concentrate 
on developing a reliable distributed search strategy for a constant search radius. 



1.2 Challenges in Robot- Assisted SAR 

There are several challenges in developing and deploying SAR robots. The most 
critical ones are summarized below. 



Unknown Environment Topology 

In a typical SAR scenario, little is known about the topology of the environment 
in which the robots are operating. In USAR, even if building plans are available 
to a robot, passages and corridors might be blocked, voids might be opened 
and in a collapsed building the entire structure might be changed. Also, in a 
WiSAR application, the terrain might be unknown, and in particular, accurate 
elevation data is not always available. This is exacerbated by the need to ex- 
pand the search radius as time progresses. 

Searching an unknown environment can be accomplished by first obtaining an 
internal representation of the topology in which the robot is operating. The 
main drawback of this approach is that time is wasted on building this internal 
map that could be dedicated to rescuing. An alternative is to learn the map of 
the environment concurrently while searching [STJ |S5j . These approaches obtain 
a probabilistic representation of the environment and are therefore not applica- 
ble to the controller framework considered in this thesis. 



Changing Environment Topology 

Even if the robot has an accurate and reliable representation of the environment 
topology at some point in time, in a real-world scenario this knowledge has to 
be updated continually. An example of an application in which this capability is 
necessary is USAR in a burning building in which hallways and staircases might 
collapse. Another example is WiSAR after natural disasters such as landslides, 
floods or earthquakes in which the landscape keeps changing. Thus SAR robots 
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need a way of detecting the environment topology and adapting their move- 
ments through the SAR site accordingly. 

This adds another layer of complexity to the task of synthesizing controllers 
that are correct by construction, since it has to be taken into account that the 
"knowledge" a robot has at each point in time might be changing. Synthesis 
guaranteeing such epistemic (knowledge-based) properties has been considered 
before j81j but not in the input-output driven way that is required for controllers. 

Due to the problems with unknown and changing environment topologies, in 
this thesis we assume a constant environment and that an accurate and reliable 
representation of the environment topology is known at specification-time, i.e. 
when the specification is written for the SAR robots. 



Cooperation and Communication 

Often a SAR task requires the cooperation of many agents. For example, finding 
a moving target can be done reliably by a single robot only in a very limited 
number of cases, see Section W^ In order to cooperate, agents must be able to 
share relevant information about their own actions and adapt their strategies 
accordingly. 

Communication between robots is governed by protocols which must be en- 
coded in the specification. However, this introduces circularity: A robot has 
to guarantee to satisfy its part of the protocol's contract only if the robot with 
which it communicates satisfies its own part. A naive formalization of this prin- 
ciple would allow the robots to exhibit any behavior in the case that no robot 
satisfies its guarantees initially. Resolving these circularities requires to im- 
pose restrictions on the specifications pertaining to communication, giving rise 
to assumption/guarantee specifications '36' and the corresponding composition 
rules, see Section [ 



Realizability and Synthesizability 

Synthesis of correct-by-construction controllers has the obvious advantage that 
the specification is guaranteed to be satisfied. However, there exist specifications 
that cannot be realized (or satisfied) by any controller. Thus, if the specifica- 
tion is unrealizable, no controller can be generated from it, independently of the 
synthesis method used. 

Not all specifications that are realizable can also be synthesized into a controller, 
depending on the synthesis method used. When choosing the synthesis method, 
there is a tradeoff between the generality of the specifications supported and 
the efficiency of the synthesis and of the resulting controllers. 

The realizability of some specifications depends on the topology of the envi- 
ronment. For example, the property "each location in the search area is vis- 
ited repeatedly" requires that the topology can be represented by a strongly 
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connected graph, see Section 14.1.11 Deciding realizability and synthesizing con- 
trollers for a particular topology can be handled reasonably well by existing 
methods. However, controllers that provide guarantees for all graphs classified 
by some user-specified properties (such as connectedness or Hilbertness) pose a 
much harder problem and is not treated here. 



Integration and Human-Robot Interaction 

One of the main challenges in developing robots assisting SAR is that they have 
to be integrated in existing organizational structures. This includes technical as- 
pects such as the tasks that a robot is capable to perform, and the improvements 
that this yields over not deploying the robots alongside human SAR personnel. 
However, legal considerations such as liability in the case of failure or lack of 
trust of team leaders in the robots' capabilities may prevent SAR robots from 
being deployed even when there are no technical difficulties or limitations. 

Moreover, the interaction of humans with the robots must be taken into account. 
One major concern is the need for trained operators that must dispatch, control 
and maintain the robots. Also, automatic detection of victims is not yet reliable 
enough for completely autonomous SAR, so human operators are required to 
interpret the sensor data [TS]. While those aspects mainly concern the search 
for the victims, automated on-site rescue and medical treatment poses a variety 
of new challenges. 



1.3 Previous Work 

The previously mentioned RoboCup- Rescue project initiated a surge of research 
in robot-assisted SAR. However, even as early as 1984, computer assistance to 
SAR has been considered by Belardo et al. |5] . Early attempts to robot-assisted 
SAR include supportive technologies for robot deployment "10", coordinating 
robots to perform rescue-like tasks [SJ [SS] and combining this with cooperative 
search [35] . 

The RoboCup-Rescue project and other similar projects simulate USAR sce- 
narios in which several robot-developing teams can test their devices and hold 
competitions. With the advancements from such early research projects, several 
SAR robots were deployed during the World Trade Center rescue response in 
2001 [13]. While robot deployment time was limited, this unfortunate incident 
provided valuable information for further development for SAR robotsjfl 

Recent research into robots assisting in tasks connected with SAR has demon- 
strated several successful implementations. Several types of robots such as 
tracked, legged and flying vehicles, snakes and even shape-shifters have been 



3 



CNN, J.D. Sutter, How 9/11 Inspired a New Era of Robotics, 07 
Sept 2011, http : //articles . cnn . coiii/2011-09-07/tech/911 . robots ■ disaster . 

[response, l_packbot-robots- disasters? _s=PM: TECH, accessed 30 Nov 2011 
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developed that allow access into damaged buildings, hazardous areas and con- 
fined spaces [HJ [351 IMl IS3] • Some of these robots have already been deployed 
in actual SAR tasks [TS I IM I IS ^ . 

Instead of focusing on the physical properties of the SAR robots, this thesis is 
predominantly concerned with the control of teams of robots. This has been 
considered previously, e.g. for building inspection and searching [371 HHJ- How- 
ever, often these teams need to perform complex tasks that can be described 
quite straightforwardly in a rule-based way, but are hard to implement manually 
into a discrete controller that obeys all the rules at the same time. A promising 
approach is to automatically synthesize correct-by-construction controllers from 
high-level descriptions |47| . 

The synthesis of correct-by-construction controllers has been considered since 
the 1960's for example by Church, Biichi, Landweber, and Rabin. Initially, 
the results were developed for very general properties, leading to a pessimistic 
outlook on the computational complexity of synthesis. Also, only recently have 
methods been developed that are directly applicable for controller synthesis [71] . 
This seminal work by Piterman et al. enabled efficient synthesis of controllers 
from temporal logic specifications and forms the basis of synthesis tools devel- 
oped at the California Institute of Technology and the University of Pennsylva- 
nia [47l [91] . The respective research groups augment the discrete controllers re- 
sulting from the temporal logic specifications with continuous controllers. Other 
approach to synthesizing such hybrid controllers that are not based on the work 
by Piterman et al. were developed by Kloetzer and Belta [30] and Loizou and 
Kyriakopoulos [55| . An overview of current techniques is given in the work by 
Belta et al., which goes beyond the techniques covered in this thesis [9]. 

Several successful examples and implementations of controllers that have been 
synthesized from high level specifications have been developed [371 EHl ISH] ■ Toy 
examples of robots moving in buildings and completing tasks include a concep- 
tual implementation of USAR j46^ . Controller synthesis has also been suggested 
to be used for vehicles competing in the DARPA Grand Challenge but for such a 
large-scale application several hurdles have to be overcome first [13] . Still, mod- 
elling and synthesizing controllers from high-level specifications for symbolic 
control and planning is becoming increasingly powerful [5] , and several software 
front-ends for synthesis of discrete and hybrid systems such as TuLiP [HI] , LTL- 
Con [43], LTLMop l27j and PESSOA ^59] have been developed since. 
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Chapter 2 

Theoretical Background 



We consider the synthesis of controllers for SAR robots that are guaranteed to 
satisfy their specifications by construction. Besides the synthesis procedure, a 
formal description language of the resulting controllers as well as a formal spec- 
ification language have to be introduced. 

In Section 12.11 we introduce an abstract model of discrete reactive controllers 
and how to reason about their properties. The synthesis procedure of a single 
correct-by-construction controller from its specification is outlined in Section 12.21 
Since several agents cooperate in an SAR scenario, compositional synthesis is 
introduced in Section [2^ 



2.1 Reactive Systems 

A controller must maintain a continuous interaction with its environment 

and the system it controls. The system can be controlled by changing set 
points of actuators, but the environment may only be sensed and not influ- 
enced by the controller. The system keeps a state that is changed according to 
the behavior of its controller and its environment. The controller maintains its 
knowledge about the system's state and thus the controller is simply considered 
to be part of the systemic 

A traditional computer program can be regarded as relation between a set of 
initial states and a set of final states, acting as state transformers. However, this 
paradigm is not appropriate for describing the program of a controller, since it 
has to refer to the controller's ongoing behavior. A controller reacts to changes 
in its inputs and its program is therefore called a reactive system [TSl. The 
behavior of a reactive system can be described by a (possibly infinite) sequence 
of states of the system. This sequence can be influenced by the environment via 
events or shared variables, which can be modelled by incorporating appropriate 
atomic propositions into the specification language. 



^In traditional control terminology the system is considered to be fully observable. 
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We consider a controller as a reactive system in discrete time. Since in this 
thesis the synthesized controllers are simulated as if they were running directly 
on digital microprocessors, this temporal abstraction is sensible. Moreover, we 
are mainly concerned with specifying and synthesizing controllers that decide 
on a robot's high-level moves, similar to the moves in a game of chess, rather 
than the robot's continuous trajectories. 



2.1.1 Fair Discrete Systems 

A reactive system can be represented as a Finite State Automaton (FSA) that 
captures how the system state evolves over time. Pitcrman ct al. suggest the 
use of a Fair Discrete System (FDSJj as an abstract computational model for 
reactive systems [71^. We make the inputs, the outputs and the state space 
explicit, as it will later simplify the description of systems consisting of several 
FDS's. 

Definition 1. A Fair Discrete System A^ is a tuple {V,X,y,Q,Q,p) con- 
sisting of the following components: 

• V — {ui,U2, ■ . ■ , Un} is a finite set of typed state variables, over finite 
domains {V(ui), V(w2), • . • , V(w„)} respectively. Let V{V) = W^^y^^u) 
denote the set of all possible valuations of all variables in V ^ called the 
alphabet of M. . 

• A" C 1/ is the set of environment variables that are controlled by the 
environment. They are also called inputs. 

• 3^ = V\X is the set of system variables that are controlled by the system 
(i.e. the actuator set points). They arc also called outputs. 

• Q C \>{y) X No is the set of states. A state q € Q is a valuation with a 
unique identifier, so there can be two distinct states corresponding to the 
same valuation. We write q\u\ to denote the value of the variable m G y in 
the state g, i.e. q\u\ e V(u). A state q satisfies a propositional formula </?, 
written q N (^ iff (y9 holds when for each occurrence of w, the corresponding 
value q\v\ e V(m) is substituted. 

• 8 is the initial condition, a propositional formula characterizing the 
initial states of A^. A state q e Q is initial iff g N 0. 

• p is the transition relation defining the behavior of the FDS. It is a func- 
tion (0 : Q — > 2'5 that takes the current state q € Q and produces a set of 
new states Q' C Q. Note that this formulation allows for nondeterministic 
transition relations by producing sets containing two or more states. If 
q' £ p{q) this is also written as q^pq' . 

D 

An FDS describes how the values of the variables in V change over discrete 
time. The concept of how time evolves and relates to real time is described in 
detail in Section [2T!2l As an FDS proceeds from state to state, a sequence over 
Q is generated. In order to reason about the behavior of an FDS, we introduce 
the concept of a computation; 



^Strictly, we introduce what is called fairness-free FDS's. Fairness requires that certain 
transitions are taken infinitely many times I73| . 

10 
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Definition 2. A computation of an FDS Ai — {V, X, y, Q, 9, p) is a (possibly 
infinite) sequence of states q = qoqiq2 • • • over Q satisfying 

(CI) Initiality: qo N 6. 

(C2) Consecution: Vj G N . j < \q\ => qj-i -^p qj. 

n 

Here \q\ denotes the length of the sequence q: it is Hq if the sequence is infinite, 
and n for a finite sequence q — qoqi . . . qn- Thus, the length of a computation 
is the number of transitions made. We also introduce the concatenation of 
two sequences ci = sqSi . . . s„ and (72 — s„+iSn+2Sn+3 ■ • ■, where ci must be 
finite, to be the sequence cricr2 = saSiS2 ■ • •, i.e. concatenations of sequences are 
written just by concatenating the symbols. 

We are only interested in reactive systems that maintain an ongoing interaction 
with their environment, hence only infinite computations will be considered. 
FDS's for which all maximal length computations are infinite are called non- 
blocking and are characterized by the additional requirement that in each state 
the transition relation allows the FDS to enter a next state: 

(NB) Nonblocking Property: Vg G Q . p{q) ^ 0. 

Moreover, any physical system has an initial state. To reflect this in our defini- 
tion of an FDS, the following property is added: 

(SP) Startup Property: 3<7o e Q . go 1= ©■ 

Definition 3. Define the (overloaded) operator Vw '■ Q ^^ V(W) to map states 
to their corresponding valuations. That is, for a state q = (u,n) € Q, Vwil) = 
V e V(W^). If W in Vw is understood from context, we simply write V. D 

The V-operator can also be used for sets, sequences and sets of sequences of 
states, mapping each element to its corresponding valuation. Moreover, V is 
used to map variables to their domains, so it is "overloaded" to yield the do- 
main V{u) for a variable u. The sets of valuations of sets of variables V, X and 
y are also defined using V as V(F), V{X) and V(3^). 



Definition 4. The set of all finite nonempty sequences over a set S is denoted 
by 5+ , and the set of all infinite sequences over S is denoted by S°° . U 

Note that by |(SP)| all computations of an FDS M. are nonempty, as M. must 



have an initial state satisfying (CI) The set of infinite computations of an 
FDS A^ is then denoted by C{M) '^ Q°°, and the corresponding set of infinite 
sequences of valuations, called the language of A^ is V{C{A4)) C V{V)°°. To 
simphfy notation, we denote the language of M by £m = V(C(A^)). 

A transition of an FDS can cither be triggered by a change of the environment 
variables, called environment-triggered, or by some external events such as 
the ticks of a system clock on a computer, called clock-triggered. In a purely 
environment-triggered FDS, no transitions can be made that merely change 
the system variables if no changes in the inputs are observed, limiting the set 

II 
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of behaviors (the language) expressible by such FDS's. However, in a purely 
clock-triggered FDS, changes in the environment variables might be overlooked 
if several such changes occur during one tick of the clock. Since the FDS's that 
we consider should be implementable on a microprocessor, we adopt a clock- 
triggered approach and account for the complications in the specifications, see 
in particular Section 13.1.51 and Section 13.2.21 

If X is nonempty, a change in the any of the environment variables in X requires 
a transition to be made. Since X is not controlled by the FDS, the nonblock- 
ing condition |(NB)| is no longer sufficient to ensure that there is always a valid 
transition available. The stronger requirement that in every state a transition 
is possible independently of the inputs is sufficient to ensure that an FDS al- 
ways maintains an ongoing interaction with its environment. However, often 
this requirement is too strong for the specification to be realizable. This issue is 
addressed by introducing assumption/guarantee specifications in Section 13.1.31 

By moving from state to state, an FDS can represent the behavior of a micro- 
processor. While an FDS can be considered as the "program" running on the 
microprocessor, it abstracts away from any specific hardware model. As long as 
a microprocessor implements the behavior of an FDS, it is sufficient to reason 
about the FDS — the results will hold for the actual implementation as well. 
Indeed, we will later show how to simulate an FDS and use this to test the 
synthesized implementations. 

While the behavior of reactive systems can be accurately modeled using FDS's, 
only very basic reactive systems can be hand-coded in a manageable amount 
of time. In order to handle large systems, a high-level system specification lan- 
guage is used to describe the operation of an FDS. Synthesis from a correct 
high-level description yields a correct-by-construction controller in the form of 
an FDS. Correctness of a system can then be methodically verified in the speci- 
fication language without having to explicitly reason about its semantics in the 
foundation logic. 



2.1.2 Temporal Logic 

Temporal Logic (TL) is a well-established formalism that can be traced back 
even to the ancient Greeks [32]. It has been formalized as Tense Logic by Prior 
in 1962 [7^ and introduced as a formal specification language for reactive sys- 
tems by Pnueli in 1977 |72) . A statement in propositional logic is interpreted 
to make a statement over the state at one given time (the present). However, 
with TL also statements about the past and the future can be made. 



The Concept of Time 

The natural concept of time is that it proceeds continuously and at a constant 
rate. In temporal logic, this concept of real-time is abstracted away in two ways. 
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Firstly, time in TL proceeds in discrete steps, that might be ahgned to clock 
ticks or other external events. The present is considered to be at time zero. A 
propositional formula p just talks about the present: 



I ^ 

p 

However, with a temporal formula , statements about several points in time can 
be made. For example, with the "always" operator, \3p we can express that p 
is an invariant over time (in the future): 
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And with the "eventually" operator. Op it can be expressed that the proposition 
p will hold at some unspecified future point in time: 



P 

Other temporal operators express similar properties. Several forms of TL are 
in use, but here we only consider Linear Temporal Logic (LTL). It is called 
"linear" because LTL formulae are interpreted over sequences of states, where 
each point in time is associated with an element in the sequence. Thus for a 
sequence of states SoSiS2 ■ • •, the element sq is said to occur at time zero, si is 
said to occur at time one and so on. These times can be the ticks of a clock. 
However, there is no correspondence to a real-time axis, which is the second 
abstraction step. Thus only the order and perhaps the number of repetitions of 
states in a sequence has semantic significance. 

After discretizing and abstracting away from real time, the "past", "present" 
and "future" get their meaning from the part of the sequence under consider- 
ation. A propositional formula talks about a particular instance in time, 
a past formula talks about (non-strictly) smaller time indices, and a future 
formula talks about (non-strictly) greater time indices. Time moves strictly 
forward, so the elements of a sequence are considered one after the other, with- 
out repetitions. 

By interpreting the abstract time in our real-world notion of continuous time, 
it can be defined what it means to execute an FDS on a microprocessor. The 
processor clock generates a sequence of ticks io^i^2 • • • that trigger the transi- 
tions of an FDS. A clock-triggered FDS Ai is executed by starting in an initial 
state qo\^Q at clock tick io- Then, before every clock tick ti,i > 0, the current 
values Xi-i G V(A:') of the input variables X are read from the environment's 
state and a transition is made from qi-i to qi s.t. V((7i)[<-f] = Xi^i, where [X] 
denotes the restriction to the variables in X. Note that the current values of 
the environment are only visible in the next state. 
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Operator(s) 


Precedence 


Associativity 


-, 0, 0, □, 0, ■, ♦ 


1 


right 


U,\J 


2 


right 


IX 


3 


right 


A 


4 


left 


V 


5 


left 


-^, o 


6 


right 



Table 2.1: Operator precedence and associativity. 



Syntax 

The syntax of an LTL formula ip over the variables V is given by the BNF 
definition 

(p::=p\^ip\ipy ip\Oip\ipU(p, (2.1) 

where p is an atomic proposition relating a variable u g F to a subset of its 
domain, v C V{u). That is, p — {u,v) £ V x V{u). An atomic proposition of the 
form p = (u, {v G V(u) | v 1X1 w}) is written simply as u M w, where w € V(u) is 
a constant and 1X1 is one of =, 7^, <, <, > or >. For a boolean variable u, the 
atomic propositions "m = True" and "m = False" are abbreviated simply by u 
and -^u respectively. 

The operator Q is called weak next or just next and U is called strong until 
or just until. Next and until arc called temporal operators, while ^ and 
V are called propositional operators. Other propositional operators can be 
defined in the usual way: 

True — ipM -^Lp 
(p Aijj — -^{^ifi V ^-0) 
ip ^ ^j = -^ip V '0 

ip^'iJj = tp^'ipAip^V 

A formula only containing atoms and propositional operators is called a propo- 
sitional formula. The following additional temporal operators can be defined: 

(y3 = TrueZ^iy9 

(p\i '4' = ipU'ip\/ n</3 

The operator is called eventually, D is called always, U is called weak until 
and is called strong next. Additionally, the temporal past operators ■ 

and ♦ can be introduced, which will be used in Section 13.2.11 However, it can be 
shown that past operators do not add expressivity [53] . A formula that contains 
no past operators is called a future formula, while a formula that contains only 
propositional and past operators is called a past formula. Operator precedence 
and associativity are summarized in Table YTa\ 
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Semantics 

Let C{V) denote the set of syntactically correct LTL formulae over the variables 
V, i.e. the language generated by (j2.ip . We now define a compositional seman- 
tics of LTL via the satisfaction relation 1= between a tuple {(J,j) € V{V)°° x No 
and an LTL formula ip G C{V). Since the semantics is defined over sequences of 
valuations V{V), LTL formulae are not tied to a particular FDS with its corre- 
sponding state space Q. If two states q and q' correspond to the same valuation, 
i.e. V{q) = V(g'), then there is no way to tell them apart in an LTL formula. 

Given a finite or infinite sequence a = soSiS2 . . . G V{V)°° U V{V)^ and an 
index j e Nq, the relation N is defined as follows: 

{a,j)^p ^ s-i\=p 

{a,j)^ipVil; <^ {crj)^^ or (cr,j)^V 

{a,j)^ipU'il} 4^ 3fc > j.(cr, fc)l=?A A (Vi.j < i < fc ^ (cr, i)N(y9). 

The semantics of the past operators ■ and ♦ is given by 

(o-, j) 1= ■ 93 ^ Vfc . < fc < j =» (fj, fc) N (^ 

(cr, j) 1= ♦ ^ ^ 3fc . < fc < j A (cr, k) 1= Lp. 

The formula p is said to hold at position j of the sequence a £ V{V)^ iff 

In this semantics Q ¥' nieans that if there is a next state, it satisfies Lp. In con- 
trast, © ip means that there exists a next state and it satisfies p. If only infinite 
sequences are considered, these two operators are equivalent. In this thesis we 
will always use Q), since only nonblocking FDS's are considered that can always 
react to a well-behaved environment. Note also that for infinite sequences 
commutes with ^ and distributes over binary propositional operators. 

Further, (pUip means that ip holds until ip holds, and ip will eventually hold, 
justifying the name strong until. In contrast, p\J ip does not require ip to even- 
tually hold (i.e. p holds forever) and is therefore called weak until. 

A formula p e 'C(T^) is said to be satisfiable iff there exists a sequence 
<T £ V{V)°° and an index j < \a\ s.t. {a,j) \^p holds. 

A sequence a G V{V)°° is said to satisfy a formula p G C{V) iff for all indices 
j < Ic], {a, j) \= (p holds. It is said to initially satisfy p iff {a, 0) N (/3 holds. The 
latter is written a\= p. 

An FDS M is said to (initially) satisfy a formula p G ^{V) iff all sequences 
(T £ Cm (initially) satisfy p. A formula p £ C,{V) is called (initially) valid 
for an FDS A4 iff every sequence a £ Cm (initially) satisfies p. If A4 initially 
satisfies p, or p is initially valid for A^, then this is written as Ai^p. 
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Specification: 



FDS: 
M 




Model Checker 



Result: 
True / False 



Figure 2.1: Outline of Model Checker 



Specification: 



Theorem P rover 



Result: 
True / False 



Figure 2.2: Outline of Theorem Prover. 

A formula (p E C{V) is said to be (initially) valid iff all sequences a E V{V)°° 
(initially) satisfy (p. If (p is initially valid, then this is written as N ip. 

An LTL formula thus can be seen as specifying a set of sequences that initially 
satisfy it. LTL is called "linear" because it can only make statements about 
paths along the transitions in an FDS. 



Other Temporal Logics in Use 

In contrast to the linear-time LTL, branching time logics such as CTL can make 
statements about entire transition trees in an FDS [21| . in particular, this in- 
cludes nondeterministic choices. There are properties that can be expressed in 
CTL but not in LTL and vice versa. Both specification languages are subsumed 
in a more general temporal logic called CTL* [35]. 

Several other logics for specifying reactive systems exist. Some are tailored for 
hardware, others for software. Interval Temporal Logic makes reasoning about 
periods of time explicit [61] . Atomic propositions in LTL make statements about 
variables at one point in time, but in the Temporal Logic of Actions introduced 
by Lamport in 1994 atomic propositions can be made over changes in variables 
that are termed "actions" 151 . 



2.1.3 Model Checking and Deductive Proof Systems 

In order to make use of specifications, it must be possible to determine whether 
a reactive system, in form of an FDS M, satisfies a given specification ip. Model 
checking determines whether ip is (initially) satisfied by Ai . The outline of this 
process is shown in Figure 12.11 
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Moreover, it is often useful to prove properties about a specification, without 
even considering the reactive system it will be applied to. Deductive proof sys- 
tems require an LTL specification ip to be supplied and will attempt to derive 
whether N 93 holds independently of a particular FDS, i.e. VAi .A4\=Lp. This 
process is outlined in Figure [^2] 



Model Checking 

In order to check the (initial) validity of an LTL formula (p over a fixed FDS M , 
a model checker can be employed. The model checker in Figure 12.11 is provided 
with if and M and returns true io all sequences a £ Cm in the language of M. , 
(initially) satisfy the specification Lp. The techniques and algorithms for model 
checking are manifold and can be found for example in [18j . 

Figure [53] shows an FDS M = (V, ^",3^, Q, 0,p) with three variables and five 
states. Each state is represented as a circle, with the valuations of the state 
variables V = {a;,j/, z} shown (the unique indices of the states are omitted). 
In this example, the partition of V into X and y is not relevant, and we may 
(rather arbitrarily) choose to have X = % and y = V. The arrows represent the 
transition relation: There is an arrow from a state g to a state q' iff q^pq'. 
There is an arrow without a source to a state q iff g N O. Then, model checking 
could for example establish that the following specifications hold for this FDS: 

ay, 

DO -a;, 

-^x A^z ^ D{^x A y). 




Figure 2.3: Example of an FDS with three variables and five states. 



^Assuming soundness of the model checker. 
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Model checking can also be useful when synthesizing an FDS from its specifica- 
tion. First, the correctness of the synthesis can be verified. Also, if the synthesis 
algorithm does not support a particular specification (e.g. the until operator, U 
is not supported by the synthesis procedure we are using), then it can still be 
verified post-hoc whether the unsynthsesizable properties are satisfied by the 
resulting FDS, even though not taken into account explicitly during synthesis. 



Sequent Calculus for LTL 

Sequent calculus is a deductive proof system that allows to prove tautologies in 
the specification language independent of a particular FDS. Proofs can even be 
automated up to a certain extent, e.g. using tools such as Isabelle [51] . 

This can be employed for example to prove the equivalence of LTL formulae, al- 
lowing for simplifications and translations between syntactic forms. Also, when 
modeling assumptions on the environment, it may be proved that they are satis- 
fiable, avoiding the "false implies everything" problem. However, the satisfiabil- 
ity problem for the fragment of LTL that we consider is PSPACE complete, and 
is NP complete for the fragment of LTL supported by the synthesis procedure 
that we use (|H1], Figure 3, see the entries for L{F, X) and L{F, X) respectively). 

Sequent calculus for LTL allows to derive temporal formulae by applying ax- 
ioms and transformation rules |32j . A temporal formula if that can be derived 
in such a way is called a theorem, written h (p. The proof system consisting of 
axiomatic sequents and rules should be sound, meaning that it is only possible 
to derive valid LTL formulae. Thus the soundness of a proof system can be ex- 
pressed by the implication h (/3 ^ N (/?. It is also desirable that the proof system 
is complete, meaning that it is possible to derive all valid formulae. This can 
be expressed by the implication N (yj => h 93. 

Theorems can be derived by purely syntactic means using sequent calculus |12[ 
muni]. This establishes a set of rules to derive theorems. Usually these rules are 
applied backwards, starting at the theorem to be proved and working towards 
axioms such as h True. 

The modus ponens is an example of a sequent calculus rule: 

\-p hp =^ q 

~q ■ 

This rule says that q can be derived by first deriving p ^ q and p separately. 
Both p and p ^ q must be similarly derived by rules in the sequent calculus, 
until one arrives at axioms such as the already presented one. 



2.2 Synthesis 

Synthesis is the automatic construction of programs and (digital) designs from 
logical specifications. It has been investigated already since the 1960's for ex- 
ample by Church, Biichi, Landweber and Rabin. The choice of the synthesis 
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algorithms depend on which specification language is used. For example, syn- 
thesis of open reactive systems from LTL has been considered by Pnueli and 
Rosner in 1989 [7S], and again by Piterman et al. in 2006 [71] and Klein and 
Pnueli in 2011 [33]. 

Other specification languages have been considered. So far, synthesis from 
branching time logic is impractical, as the general problems of synthesis from 
CTL and CTL* specifications are in the complexity classes 2EXPTIME and 
SEXPTIMEcJ respectively [49,, and to our knowledge, no methods are available 
that perform better on a reduced set of specifications, although an interesting 
approach is suggested by Antoniotti and Mishra [4]. Synthesis of open con- 
trollers from Probabilistic CTL [1 [7] is in NP n co-NP ^. 

We consider the synthesis problem to be to find an FDS Ai that initially 
satisfies a given LTL specification ip, i.e. Vc G Cm . cr 1= </j. This is shown in 
Figure 12.41 where the synthesizer is only provided with the specification. 



Typically, synthesis is preceded by deciding realizability of the LTL specifi- 
cation, which amounts to checking whether there exists an FDS Ai initially 
satisfying (p, see Figure [531 

Specification: r~ I FDS: 

> Synthesizer ^ . . 

f M 



Figure 2.4: Outline of Synthesizer. 



Specification: 



Realizability Check 



Result: 
True / False 



Figure 2.5: Outline of Realizability Check. 



2.2.1 Game Theoretic Approach 

We use the synthesis tool by Piterman et al. fTT which solves the synthesis 
problem by viewing it as the solution of a two-player game. The synthesized 
FDS is the controller of the system and acts against its adversary, the environ- 
ment. The output variables of the FDS directly control the system and thus 
it is viewed as part of the system. The game is then between the controller 
and the environment with the utility function being formulated in terms of the 
behavior of the system: The goal of the game for the system is to satisfy its 
specification, which the environment tries to prevent. For an introduction into 
game theory see for example the book by Nisan et al. [65) . 



"The complexity classes 2EXPTIME and 3EXPTIME contain algorithms with worst-case 
complexity 2^ and 2^ respectively, where p{n) is a polynomial in the input size n. 
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X H M ^3^ 



Figure 2.6: The synthesized controller as an FDS 

Consider the FDS M in Figure 12.61 It represents the synthesized controller with 
inputs X (the environment variables) and outputs y (the system variables) . The 
environment and the controller are allowed to influence exclusively the environ- 
ment and system variables respectively. From the point of view of the controller, 
these can be seen as the measured state of the system and the inputs to the 
system respectively. Thus the controller can "react" to its observed changes in 
the environment variables by changing the system variables. 

The controller and the environment are taking turns in the game. Due to the 
adversarial nature of the environment it is assumed to always take the worst 
possible move evaluated against the utility function of the controller. The en- 
vironment is also thought of as having perfect knowledge about the controller's 
state and strategy, i.e. its transition relation. However, the controller only knows 
the current observable state of the environment, and possibly the history of en- 
vironment states that the controller has stored. 

The utility function of the controller can only take one of two values, corre- 
sponding to satisfying and violating its specification. The synthesis procedure 
therefore tries to find a winning strategy for the controller, implemented as an 
FDS, that maximises this utility by ensuring that the specification is never vio- 
lated. Such a winning strategy only exists if the specification is realizable. The 
possible solutions are equilibria in which both the controller and the environ- 
ment cannot improve their outcome by changing their respective strategy (i.e. 
Nash equilibria). However, these strategies are by no means unique, and thus 
several FDS's implement the same specification. 



Closed and Open Systems 

A system that does not interact with its environment is called closed. The com- 
putations of such a system do not depend on the environment, and therefore 
this is modelled by having an empty set of environment variables X. A system 
that generates its inputs nondeterministically by itself can also be regarded as 
a closed system. 

In contrast, a system interacting with its environment is called open. This is 
modelled by having a nonempty set of environment variables X. For the system 
to be open it is necessary that it does not control its environment, in the sense 
that it cannot directly infiuence its environment variables. 

For the synthesis of an open system, it is irrelevant how the variables in X are 
controlled - they might be controlled partially or entirely by another FDS as 
shown by V in Figure [T71 However, all the variables that are not controlled 
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X 



-0 



,0, 



Figure 2.7: The controller M with its environment, V . Note that V does not need 
to be an FDS. 



by the system are considered to be part of one single environment. One way to 
close an open system, which is necessary for simulation (see Section l5 .1.11) . is by 
synthesizing an FDS (or a set of FDS's) obeying the environment assumptions 
and connecting it to the system. This is explained in detail in Section [ 



2.2.2 Computational Considerations 

Synthesis of LTL formulae for general specifications is 2EXPTIME-complete [7T] . 
However, for a subset of assume-guarantee specifications called Generalized Re- 
activity [1] (GR[1]), synthesis can be performed in cubic time in the number of 
conjuncts in the specification and in the number of possible valuations of the 
system and environment variables (Theorem 1, |71|V GR[1] formulae are ex- 
plained in detail in Section [3.1.41 

While the implementation of an FDS would typically be run on an embedded 
processor with lower computational power, a high-performance computer can 
be used for synthesis. Thus, efficiency of executing an FDS is often more im- 
portant than how much time and memory it takes to synthesize. Once an FDS 
is loaded into memory, transitions can be performed in 0(1) time. 

One of the main considerations is therefore the space requirements of the synthe- 
sized FDS. The larger the state space, the more memory is required for storage. 
In the worst case, the space requirements grow quadratically with the size of 
the state space. This is the case when the graph representing the FDS's tran- 
sition relation is dense, i.e. when there are transitions between almost any two 
states. Sometimes this can be alleviated by strengthening the assumptions on 
the environment, since then the transitions can be removed that are precluded 
by the assumptions, and would never be taken under correct execution. 

Note that if an environment variable changes so that no transition is available, 
the FDS blocks. This can only be the case if the environment assumptions are 
violated, and so the specification still holds even in that case. While this is 
important to be able to reduce the amount of available transitions during syn- 
thesis, such behavior of course is not useful in practice. 
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2.2.3 Synthesis Software 

The synthesis tool used in this thesis is based on the work by Piterman et al. 
[TT] , Synthesis of an LTL specification proceeds in several steps. 

First, a Game Structure is constructed from the specification, separating the ini- 
tial conditions, the formulae specifying the transition relation, and the formulae 
for the game's goals. Then, the realizability of the specification is checked by 
solving a ^-calculus formula [IS] that corresponds to the Game Structure [55] . 
This can be done by the Temporal Verification System (TLV), a software tool 
for computer-aided verification [TQ . Once the /x-calculus formula has been suc- 
cessfully solved (which can only be done if the specification is realizable), the 
intermediate values from the solution process can be used to construct an FDS 
satisfying the specification, which is again done by invoking TLV. Piterman et 
al. describe the details of these back-end activities [7T] . 

The front-end that we use is TuLiP, a Python-based software toolbox for the syn- 
thesis of embedded controllers developed by Wongpiromsarn et al. [HI] . Given 
an LTL specification, it provides the appropriate inputs for the synthesis to 
TLV. Its backend is based on JTLV, a Java-based implementation of TLV [77] . 
TuLiP supports the synthesis of FDS's from GR[1] specifications. This restricts 
the set of realizable formulae to those that are in this particular syntactic form. 
Also, the JTLV backend works with Binary Decision Diagrams that sometimes 
cannot resolve formulae that are in the form D P- 

The specifications that we develop in this thesis were encoded into the appropri- 
ate format for TuLiP to process them. TuLiP is then invoked simply by Python 
function calls. 



2.3 Compositional Synthesis 

In the previous section, the synthesis of a GR[1] formula into a single FDS has 
been considered. In this case, the synthesis is based on a two-player game of 
the system against the environment. However, it may sometimes be necessary 
to synthesize several reactive systems that together satisfy one global specifi- 
cation (f. This is called compositional synthesis. It is required when several 
players need to coordinate with each other in order to "beat" the environment. 



Motivations for Compositional Synthesis 

An FDS represents the program of a physical or logical entity. For example, 
an FDS might be executed as a thread on a processor. If there are several 
FDS's that are connected with each other, they are also called components. 
The connections between the components are described by an architecture, 
which is formally defined in Section 12.3.31 When considering one component in 
the architecture, all other components will be called its peer components or 
simply its peers. 
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Specification: 




Distributed Synthesis 



FDS's: 
^{Mi,M2,...} 



Architecture: 



Figure 2.8: Outline of Compositional Synthesis 



Each component might be executed on a different processor, or as a different 
thread on the same processor. This imposes restrictions on which variables 
can be accessed and modified by each component. Often the physical topology 
naturally imposes restrictions on the architecture supplied to the synthesis pro- 
cedure. 

The specification ip provided to the synthesis procedure is an LTL formula over 
variables in some set V which is partitioned into X and y, the global environ- 
ment variables and the global system variables respectively. Synthesizing 
a single FDS means that all system variables in y can be freely manipulated 
without any constraints. If there are several components, then the components 
may only manipulate disjoint subsets of 3^. This avoids inconsistencies by allow- 
ing each variable in y to be manipulated by at most one component. However, 
each variable in V may be read by several components. 

A specification ip need not refer to all variables in y. It might be necessary to 
introduce additional variables that are only relevant locally to the individual 
components (cf. Section [2. 3. 5|) in order to implement communication protocols 
between the components. Such protocols are of no concern in the global specifi- 
cation and hence are abstracted away. Still, it is necessary that these additional 
variables are treated as system variables, and thus are in the set y. 



2.3.1 Game Theoretical Approach 

Compositional synthesis can be seen as solving a multi-player game by finding 
a set of strategics that obey both the game's rules (the global specification) and 
the topology of communication (the architecture). The players should cooper- 
ate with each other in order to beat an adverse environment. 

Synthesizing such cooperative strategies is hard and in general undecidable [75] . 
Another way to approach this problem is to recast it into a set of two-player 
games in which each component acts against all other components and the 
environment. Since cooperation can be achieved by negotiating according to 
predefined protocols, the set of realizable global specifications is limited. 
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Negotiation is part of a strategy and thus can be treated using the same kind 
of specifications as in the rest of the strategy. It is required to estabhsh co- 
operation patterns such as deciding which robots should rescue a target and 
which ones should keep searching. When synthesizing strategies for multiple 
two-player games, the negotiation channels, i.e. who negotiates with whom and 
for what, must be explicitly encoded in each component's specification. This 
limits the scope of negotiation, but will lead to a substantial reduction of the 
state space. This is because the components can make local decisions that to- 
gether satisfy the global specification, and thus lead to the system maximizing 
its utility. This is ensured by decomposing the specification appropriately before 
synthesis. Thus the decomposition into multiple two-player games is not done 
by the synthesis procedure, as, in fact, this would still be undecidable. 



2.3.2 Computational Considerations 

The two main considerations in compositional synthesis are realizability and the 
size of the state space. A specification might be realizable for a single FDS, but 
not for a distributed architecture. This results from the restrictions on which 
variables can be controlled by each individual component, which may severely 
limit the extent of coordination between the components that can be mustered 
to beat the environment. 



State Space Reduction 

Compositional synthesis is a reasonable approach to the state space explosion 
problem. A single FDS with n boolean variables may contain up to 0(2") 
states. If the system can be decomposed into N subsystems of n/N + m vari- 
ables, where m is the number of variables needed for communication in each 
component, then each component would contain only up to 0{ \/2"2™) states. 

If m is small enough, this can result in fewer states per component. However, if 
each component receives full information about the state of each of its peers, m 
has to be large and this might cause even more states in each component. This is 
because in this way each component has full global information and additional 
variables are required for reliable transmission, and hence the decomposition 
does not result in a reduction of the state space. By fixing negotiation patterns, 
it is actually possible to satisfy the global specification by using only local in- 
formation. 

Therefore, it might sometimes be desirable to decompose an FDS even if no 
physical communication restrictions are present. In fact, this might be the only 
way to practically synthesize a specification within reasonable time and for a 
given amount of memory. 
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Realizability 

When reasoning about the reahzabihty of a specification in compositional syn- 
thesis, the required architecture has to be taken into account. The architecture 
imposes constraints on the variables that each component can manipulate and 
thus not all global system variables can be arbitrarily influenced, as is the case 
in a centralized design. 

Realizability of a specification depends primarily on the architecture and how 
the components communicate. If the architecture is in form of a "pipe" , i.e. a 
purely serial interconnection in which only the first component receives inputs 
from the environment, then realizability can be decided. However, even for ar- 
chitectures not much more complicated, for example those involving feedback, 
realizability is undecidable [321 ^M\ ■ 

That does not mean that no feedback communication is realizable, but that no 
algorithm can be expected to decide realizability for any given specification and 
architecture. By performing the decomposition into specifications satisfying the 
architecture before synthesis, many global specifications can be realized, even if 
distributed synthesis of the global specification is undecidable. 



2.3.3 Architectures 

Compositional synthesis requires not only a global specification ip, but also in- 
formation on how to split up the tasks between the players and their means of 
communication. This is captured by an architecture £/ . The synthesizer there- 
fore gets both the specification ip and the architecture £/, and outputs a whole 
set of FDS's M = {A^i, M2, ■ ■ ■} that together satisfy the specification and the 
architecture. This is illustrated in Figure [2781 



Definition 5. An architecture ^ is a set of pairs {{Xi,yi) \ i G /}, where / C 
N is a finite set, indexing the components, for which the following restrictions 
hold: 

(Al) : Vi G / .{Xi C y) A (3^i C V), all variables in the architecture are global. 

(A2) : yi,jEl.{iy^ j) => (J^i n J^j = 0), no variable is controlled by more than 
one FDS. 

(A3) : Vi G I .{Xi n J^i = 0), no component controls its environment. 

n 

The sets Xi and 3^i represent the environment and system variables respectively 
of each FDS in M. Still, each component may have some of its environment 
variables controlled by the global environment, and some by peer components. 
The variables controlled by the global environment will be denoted £i C Xi. 
The environment variables of a component Mt controlled by its peer Aij will 
be denoted by Ttj and are called transmission variables^ Given an architec- 
ture, the state variables are V — [Ji^j{XiUyi), the global environment variables 



^Clearly 7i,i = for all i, because no component controls its own environment. 
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" ' MA-Jf''-Q)^' 



^5i 
Figure 2.9: Composition of two components into a composite FDS. 

can be obtained from X = Uie/ '^A Uie/ 3^j' ^'^id the global system variables 
are y = V\X. Also, £i — '%'AUie/3^j ^^'^ Tij = Xi Ci yj. The variables in 
Si are controlled by A4i and represent the system variables that are relevant in 
the global specification. 

The set of components M = {A4i | i G /} is said to satisfy a given architecture 
£/ = {{Xi,yi) I i e /} if the input variables of A4i are Xi, its output variables 
are J^i and its state variables are Xi U 3^i for all i E I. If M satisfies £/, then 
this is written as M N jz/. 

Consider for example the distributed architecture in Figure \T^ It shows two 
components Mi and 7M2 and how they are connected by the choice of variables: 
Ml can control the variables in 3^i = 5i U 7i^2, where Si and 7i,2 niay have a 
nonempty intersection. The variables in A"! = £1 U 7i,2 cannot be controlled by 
Ml. Instead, Mi considers them to be controlled by its environment. £1 and 
7i,2 are disjoint, where 7i,2 is controlled by M2- However, from the point of 
view of A^i, it is irrelevant how the variables in Xi are controlled. Thus, 

Mi = ( fiu5iuri.2ur2,i^ ,giuri,2,^iur2,i,gi,9i,pi) (2.2) 

and symmetrically 

M2 ^ ( ft u ^2 u ri,2 u r2,i ,g2 u Ti,2,s2 u r24, gz, 62,^2). (2.3) 

V2 X2 y2 

2.3.4 Composition 

An architecture merely describes the connections between the individual com- 
ponents. As stated above, compositional synthesis has to produce a set of com- 
ponents that satisfy both the architecture and the global specification ip. So far, 
we have only defined what it means for a single FDS to satisfy its specification. 
Therefore a formal description of the behavior of a set of components is required. 
The idea is to compose the FDS's in M into one larger FDS M that generates 
computations over the variables V. This FDS is called the composite FDS. 

In a synchronous composition, the FDS's proceed in lock-step, i.e. they all 
make a transition at the same time. This would be reflected by the composite 
FDS M making a transition if and only if all FDS's in M make a transition. 
Considering that typically each FDS is executed on an individual processor. 
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this requires their clocks to be precisely synchronized and communication to be 
implemented with negligible latency. These assumptions can usually not be sat- 
isfied in practice, but still this form of composition is often a topic of theoretical 
interest gOlIZS]- 

Instead, in an asynchronous composition the execution does not have to be 
in lock-step and therefore no synchronization is required. Communication is 
still assumed to be with negligible latency, but this can often be relaxed when 
adapting the local specifications accordingly. The composite FDS Ai then pro- 
ceeds even if only a single FDS in M makes a transition^ In order to simplify 
notation, the following definition of an asynchronous composition is only stated 
for two FDS's, but it can easily be extended for an arbitrary number of FDS's. 



Definition 6. The asynchronous composition of the FDS's 

Ml = { £i USiU Tig U Tz.i , El U Ti,2,Si U Tag, Qi, 61,^1), 

A^2 = (£2U£2U 724UJ^- ^2 U r2a, ^2 U ri,2, Q2, 62, P2) 
V2 X2 y^ 

is the composite FDS 

Mx\M2^ (Fi U 1/2, f 1 U £2, iVi U 3^2, Qi X Q2, ei A 62, p), 
V X y Q e 

where the transition relation is a function p : Qi x Q2 ^ 2*^1^'^^ such that for 
all (91,92), (91,92) e Qi X Q2, 

(91,92) e P(9l,92) -^ q'le pi{qi) A (92 = 92) V 
92 ep2(92)A(9l =91) V 

91 e Pi(9i) A92 e ^2(92), 

or equivalently 

(9i,92)->p(9i,92)^ (9i^Pi9'i)AVri,2(9'i)=Vri,2(92)A(92 = 92) V 

(91 =9i) A (92^^292) V 
(91 ->pi 9l) A Vr,,i(92) ^ Vr,,i(9i) A (92 ^p. 92)- 

n 

Note that in order to model asynchrony, the values of the transmission variables 
7i,2 and 72, 1 are only equated between qi and 52 in a transition of A^i and M2 
respectively. 

The asynchronous composition is in this thesis also referred to simply as compo- 
sition. Composition is both associative and commutative. That is, A^i | AI2 = 
M2 \Mi and (A^i | A^2) | M3 — Mi |(A^2 {Ms) for any components Mi, M2 



®The standard definition of asynchronous composition prohibits two FDS's to make a 
synchronous transition. 
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and Ms with appropriate environment and system variables. Thus, the paren- 
theses are usuaUy dropped and an arbitrary (finite) number of components can 
be composed to obtain a composite FDS. 

Defining the composition of FDS's to be an FDS in its own right has one major 
advantage: Since LTL specifications are statements over sequences, the global 
specification tp can directly be used to make statements about the composition. 
For example, for the composite FDS Ai = A4i\A42\- ■ -lAin, the statement 
A4\^ (fi is already defined to mean that Vcr e Cj^-^ | y^^ |-- 1 M„ ■0'\^(p. 

The definition of an architecture allows some variables to be system variables 
of one component and environment variables of its peers. These transmission 
variables are used in communication protocols and the behavior of the compos- 
ite FDS Ai depends on when a change in these variables is seen by the peer 
components. 



2.3.5 Decomposition 

Distributed synthesis is based on a single global specification ip and an archi- 
tecture £/. The specification describes how the asynchronous composition of all 
components in the architecture has to behave, but makes no explicit statements 
about the behavior of the individual FDS's. 

The compositional synthesis problem is to find a set of FDS's so that their 
asynchronous composition satisfies the global specification. If the architecture 
defines decoupled or weakly coupled components (i.e. there are no or few trans- 
mission variables), this can be done without introducing too many additional 
states in the synthesized components. Since general compositional synthesis is 
very hard and might even be undecidable, compositional synthesis algorithms 
are typically built around the synthesis of a single FDS from its local specifica- 
tion. A separate decomposition algorithm is used to obtain the FDS's satisfying 
jz/ from the global specification. 

Two principal approaches for decomposition exist: In postdecomposition, the 
global specification is synthesized into a single FDS which is then decomposed 
according to the architecture (see Figure 1^.101) . In predecomposition, the 
global specification is decomposed first into several local specifications that are 
then synthesized separately (see Figure 12.111) . Both post- and predecomposition 
require the resulting synthesized components to satisfy the architecture. 

The approach that is adopted in this thesis is predecomposition. Let f be the 
global specification, and £/ be an architecture. A set of local specifications 
{tpi I i G /} is a predecomposition of a global specification (p iff any set of FDS's 
M = {Mi \ i E 1} that satisfies the architecture £/ and for which A4i V^ipi for 
all i £ I, the asynchronous composition A^i|7V{2|'''|A^ri satisfies the global 
specification ip. That is, the local specifications ipi, (p2, . . . ,(pn must satisfy 

(PD) : yM = {M^ I i e 1} .M^j2/A{yi e I .M^^ip^) ^ Ml\M2\- --{Mn^^- 
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Specification: 



Architecture: 




Figure 2.10: Outline of Postdecomposition. S is the synthesizer and Dpost performs 
the postdecomposition. 



Specification: 



Arclritccturc: 



Local Specifications: 

■ip2 ■ 




Figure 2.11: Outline of Predecomposition. Dpre performs the predecomposition, 
and then the same synthesizer S is invoked several times. 
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The decomposition of a global specification into such local specifications is dis- 
cussed in Section [31 To our knowledge no general systematic approach has yet 
been developed. The undecidability of compositional synthesis for almost all 
architectures makes a fully automated approach unlikely. 

This is why in the next chapter we develop approaches to manually decompos- 
ing the global specification. While we consider the restrictions imposed by the 
architecture on the global system variables that occur in the global specification, 
the architecture may be enhanced with additional transmission variables if this 
is needed. 
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Chapter 3 

Specification 



The reactive controllers of the SAR robots decide on the actions of the robots 
in order to find and rescue the targets. As described in Section [2.2.11 and 
Section 12.3.11 the controllers are thought of as players in a game that is subject 
to a set of rules, has a goal and an initial configuration, similar to a board game. 
However, board games are usually described informally in prose, which is prone 
to ambiguities, contradictions and omissions. 

Instead, formal specifications can be used to precisely describe the behavior of 
software and hardware systems [TTl [331 El] • The two most common scenarios 
are to use the specification to verify a given system (see Model Checking in 
Section [2. 1.3|) or to synthesize a system that satisfies a specification by con- 
struction (see Section [ 



A specification language should facilitate the development of specifications sat- 
isfying the following requirements [74) : 

Incremental Modification Once a specification is finalized, it should be easy 
to add another requirement, or relax an existing one. 

Consistency There should exist at least one system that can actually satisfy 
the implementation. This property does not, however, state that such a 
system can be found in a straightforward manner. 

Completeness A specification should include all important properties the sys- 
tem has to satisfy. 

Validation From a specification, it should be possible to check whether an 
implementation satisfies the designer's intentions. This is not the same as 
verification, since an implementation that satisfies a formal specification 
might still not do what the designer wants. Validation is an informal 
process, and so the specification language should be semantically closely 
related to the specification-relevant subset of natural language. 

Scalability The specification language should be suitable for large systems. 

Incremental modification, consistency and validation are all viable in LTL. How- 
ever, the completeness of an LTL specification is very difficult to verify, which 
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also restricts the scalability of specifications. Notwithstanding these limitations, 
LTL has become a common way to express properties of reactive systems. We 
therefore investigate how to use LTL as a specification language for controllers 
that fit into the game-theoretic paradigm, as well as taking into account the 
input-to-output characteristics of standard controllers. 

A specification for an FDS M = {V, X, y, Q, 9, p) is an LTL formula ip e C{V) 
over the variables V . Similarly, a program then satisfies the specification if tp is 
valid for any FDS A4 describing the program. Note that there might be several 
FDS's describing the same program and vice versa. 

A property over the variables V^ is a subset of the sequences in V{V)°°. An 
LTL formula (p G C{V) then expresses the property {a £ V{V)°° \ a\=ip}. Not 
every property can be expressed by an LTL formula, since the properties ex- 
pressible by LTL are countable, but the set of all properties, 2^^^^ is notl^ Also, 
the expressivity of LTL is limited by the (bounded) nesting depth of the next 
operator [48] . 

Since we are only concerned with properties expressible in LTL, we use the 
terms property and formula fairly interchangeably if the context is clear. Also, 
given a formula (p, the corresponding property can be found by forming the set 

{ere V(y)°° \a\=p}. 

In this and the following chapters, intervals of integers are denoted in the fol- 
lowing way: [a,b] = {x £ Z \ a < x < b} and [a,b) = {x G Z \ a < x < b} for 
integers a and b such that a < b. Also, the boolean domain {0, 1} is denoted by 



Often, integer variables are used to represent data storage. To represent that a 
storage is empty, the integer —1 may be used. For better readability we use e as 
a synonym for —1, and so the intervals [e,n) and [e,n] are the same as [— l,n) 
and [— l,ril. 



3.1 Classification of Formulae 

Specifications for reactive systems typically consist of both safety and liveness 
formulae. This classification was first introduced by Lamport in 1977 'SOj. Later, 
Manna and Pnueli gave an entire taxonomy in the form of a "hierarchy" to clas- 
sify different formulae [57| . 

This classification also contains elaborate formulae such as assumption/guar- 
antee (A/G) and GR[1] specifications, which are introduced in Section fS.l.BI 
and Section 13.1.41 respectively. One important attribute "orthogonal" to the 
classification between safety and liveness is whether the sequences satisfying a 
formula are invariant under finite repetitions of elements, which is discussed 
in Section [5.1.5l 



^Here 2® denotes the powerset of a set S. 
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3.1.1 Safety and Liveness Properties 

Informally, a safety property states that "nothing bad will ever happen." In 
the specification of control systems, safety properties ensure that constraints 
are never violated. A formula ips expressing a safety property then states that 
all finite prefixes of a computation a satisfy some propositional formula p. 

According to Sistla [53] , i^s is a safety formula iff all sequences a for which all 
finite prefixes can be extended to an infinite sequence satisfying (ps, satisfy ^s- 
Denoting the set of finite prefixes of a sequence a by pref{a), this statement 
can be written as 

(Vct e V(y)°° . Vo- e prefia) . 3a e V{V)°° .aa^ips) => a^ips. 

Any safety formula can be written in the form D p, where p is a past formula. 

Deciding whether a given set of sequences is a safety property is PSPACE- 
complete ([53], Theorem 5.5). However, it has been shown that safety formulae 
are closed under A, V, Q, U and D ([53], Theorem 3.1). Of course, then safety is 
also preserved under weak until U, but not necessarily under strong next for 
finite sequences. These syntactic properties provide an efficient way to decide 
whether a given formula expresses a safety property. 

A liveness property states that "something good will eventually happen." 
Therefore, a liveness formula tp^ expressing a liveness property requires that 
every finite squence a can be extended to satisfy lpl. That is, if a]^ipL then 
there exists a possibly infinite sequence a so that the concatenation of the two 
sequences aa satisfies piL- Formally, ip^ is a liveness formula iff 

V(T e V{V)+ .(crJ^ LpL^3d e V(F)°° . aa N lpl). 

Liveness formulae are necessary in the specification of reactive control systems 
in order to ensure that the controller maintains an ongoing interaction with its 
environment. If no liveness formula is included in a specification then it can be 
satisfied by sequences consisting only of the initial state (or a finite number of 
states.) This becomes an issue when synthesizing an FDS from such a specifi- 
cation not containing a liveness formula, since the synthesis algorithm will try 
to generate the simplest possible FDS, which does not need to be nonblocking 
in this case. 



3.1.2 Derived Classes 

Several important and widely-used classes can be derived from the safety and 
liveness classification [ST] |90] . We present these classes using past formulae p 
and q. However, since we only consider future formulae for synthesis, p and q 
are propositional formulae (which are both past and future formulae). 

A guarantee formula is of the form P- It is therefore a liveness formula and 
expresses that the system must eventually satisfy the formula p, e.g. termina- 
tion in a total correctness specification of a program. 
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An obligation formula is a combination of safety and liveness formulae of the 
form Dp V ()q. Such formulae can specify the behavior in exceptional circum- 
stances. For example, n-'pVO(p O q) ensures that either the exception p never 
happens and if it does, it is handled correctly by q. 

The class of obligation formulae strictly contains the safety and liveness formu- 
lae and so a general obligation formula cannot be specified by either a safety or 
a liveness formula. Every boolean combination of safety and guarantee formulae 
is an obligation formula. 

A progress or recurrence formula is of the form D P and expresses that p 
has to be satisfied at infinitely many positions. If p is a propositional formula, 
then a progress formula is a liveness formula. However, if p is allowed to be any 
past formula, then the class of progress properties is strictly greater than that 
of obligation, safety or liveness properties. 

A response formula is of the form \3{p — J- (?) and ensures that the formula q 
will hold at some point in the future whenever p is satisfied. Response formu- 
lae are progress formulae, and if both p and q are propositional formulae then 
they are even liveness formulae, since they ensure that q is always asserted as a 
reaction to p. 

A stability or persistence formula ensures that once a proposition p holds, it 
will never be violated in the future. Such a formula is of the form (}0p. It can 
be understood as requiring the system to enter into a stable state characterized 
by p, and remaining there. The class of stability properties is strictly larger 
than the class of obligation, recurrence and persistence properties. 

A reactivity formula is of the form D P V □ 9 and is a combination of a 
progress and a stability formula. The class of reactivity properties is strictly 
larger than any of the abovementioned classes. An even larger class of properties 
is that of the general reactivity properties, which contains sequences satisfy- 
ing finite conjunctions of reactivity formulae. Thus a general reactivity formula 
is of the form A"=i [□ OPi V <0 D qi] where pi and qi are past formulae. Every 
formula specifiable in LTL can be expressed as a general reactivity formula [5 7) . 

The format of general reactivity formulae gives the idea for the classification of 
GR[1] specifications introduced below in Section [3.1.41 Since every LTL formula 
is expressible as a general reactivity formula, also GR[1] formulae are surpris- 
ingly expressive, even if the restrictions imposed on pi and qi are quite severe. 



3.1.3 Assumption/Guarantee Specifications 

When synthesizing open controllers from LTL specifications, a two-player game 
is considered, in which the controller plays against an adversarial environment. 
The controller tries to win by satisfying its specification while it assumes that 
the environment always tries to falsify the specification with the moves it is 
allowed to make. 
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Since the environment is considered to be adverse, it may always do the worst 
possible move from the controller's point of view, open controllers cannot be 
expected to satisfy their specification in all environments. An open controller 
interacts with an environment it cannot influence, so the assumptions it has 
about the environment do not actually constrain the environment. The con- 
troller cannot prevent the environment from violating the assumptions but in 
this case it is allowed to also violate its goals. 

The synthesis procedure only supports the synthesis of an FDS satisfying a 
single specification ip, without any explicit assumptions on the environment. 
However, since the environment and system variables play different roles in the 
synthesis algorithm, the specification cp can be written in a format that makes 
explicit what is assumed of the environment and what is guaranteed by the 
controller. 

Let (fi^ be the environment assumptions, i.e. the formula describing exactly 
what the system may assume about the environment. Let (p" be the system 
goals, i.e. the specification that the controller is supposed to satisfy given that 
the environment satisfies its assumptions. It is then sufficient for the synthe- 
sized FDS to satisfy the specification ip'^ —i' ip'' . 

Such a specification is called an assumption/guarantee specification (A/G 
specification for brevity,) and was first introduced by Misra and Chandy in 
1981 [BU]. The controller is implemented to satisfy ip^ given ip"^, but has no 
knowledge about the actual implementation of the environment. It cannot as- 
sume that an actual FDS is controlling X according to ip^. If there was such an 
FDS, (p'^ would never be violated, so it would not be necessary to even include it 
in the original specification. In contrast, the system only needs to satisfy tp" as 
long as the environment satisfies ip'^ and if (/3^ is violated, the system is allowed 
to exhibit any behavior. 

A/G specifications are mainly used to specify open controllers that communicate 
with each other. The environment assumptions of components that communi- 
cate with each other can be thought of as specifying a communication protocol. 
A component assumes that its peers comply with the protocol, and only if this 
is the case is it required to also satisfy the protocol itself. If the environment 
violates the protocol, the component also is not required to be able to satisfy it. 



3.1.4 GR[1] Specifications 

A/G specifications are very useful in defining open reactive systems. However, 
since we are concerned with synthesizing FDS's from their specifications, the 
class of formulae that we can use is restricted by the capabilities of the synthe- 
sizer. Thus, even a realizable specification (i.e. one for which an FDS exists) 
might not be synthesizable. 

Synthesis of general reactivity formulae is 2EXPTIME-complete [7B^ , but there 
exist smaller classes of formulae that can still express a large class of useful 
properties but exhibit better computational complexity for synthesis. The class 
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of A/G formulae supported by the JTLV synthesizer is caUed Generalized 
Reactivity[l] (GR[1]). Synthesis and checking realizability of such formulae 
can be done in polynomial time, see Section r2. 2.21 A GR[1] formula is of the 
form 

Vtmt A (/3t A (^^ ^ (pf„,t A ifl A ifl- 

where the superscripts e and s stand for the environment assumptions and the 
system goals respectively. A GR[1] formula thus states that only if some assump- 
tions on the environment ip"^ = ff^n A (p^ A (pg are satisfied, then it is required 
that the controller satisfies the specification ip" = (pf^^^Aip^Aipg. In particular, if 
the environment violates p"^ , then no restrictions on the controller apply. More- 
over, once a safety property is violated, it cannot be satisfied in any future state. 

In the above definition, iPi^u ^-i^d ipf^u ^^^ propositional formulae over X U y 
and characterize the initial states of the environment and the controller respec- 
tively. Synthesizing an FDS from a GR[1] specification will determine the initial 
condition Q, assuming that the environment initially satisfies ^Init- Since by the 
startup property |(SP)| each FDS has an initial state satisfying 0, it is necessary 
to have N e ^ l^p'l^^^ A (pf^^). 

Further, ip^ and pf are safety formulae of the form /\^^j\3Bi, where Bi is a 
boolean combination of atomic propositions p over variables in A" U 3^ and of 
expressions of the form Qp, where p is an atomic proposition over variables 
in X for Lp^ and over variables ith X Vjy for i^f . With this part of the GR[1] 
formula it is possible to constrain or force transitions of an FDS by using the 
next operator. Note however, that in the environment assumptions nothing can 
be said about the next values of the system variables y. 

Lastly, p'i and p)^^ are liveness formulae of the form Aie/ □ ^i where the Bi 
are propositional formulae over variables in Xuy. These properties can be used 
to ensure that the controller is not idle as long as the environment is making 
transitions. 

While GR[1] formulae might seem restrictive at first sight, they allow the ex- 
pression of many useful properties of reactive systems. Let 

r= /\ apl, A /\ OpI, a /\ {apl, V Og^,,) 

jeJi J&J2 jeJa 

A /\ DOpI, A /\ Diplj^Oqlj)A /\ ODpIj 

be a formula composed of safety, guarantee, obligation, progress, response and 
stability formulae, where Pk,j, Qsj and q^j are propositional formulae over the 
variables in V. Further, let 

0^= /\npl,A /\oOpI, 

ieii ieh 

be a formula composed of safety and progress properties, where pk,i are proposi- 
tional formulae over the variables in X , and let 4>init be a propositional formula 
over V . It has been shown that any formula of the form (0i„it ^<t>'^) — >• 0^ can be 
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translated into a GR[1] formula ([90], Proposition 1). For example, a response 
property n(p -> Oq) that has to be satisfied by the system can be translated 
into a GR[f ] formula by introducing an auxiliary boolean variable t and letting 

^tmt = -t ^ (p A -^q) 

^t - □(((-* V Op) A O -9) ^ O -t) 

ADi^tAQt^Oq) 
ADitAO^t^Op) 
^l = DOt. 

The variable t is called a trigger, because it triggers q to be asserted eventu- 
ally. The trigger is asserted as long as there is no obligation to assert q. Thus, 
when t is lowered, the system must assert q. Initially, "i = True" holds un- 
less p A -ig, the only case in which there is an obligation to eventually raise 
q. The three conjuncts of tpf ensure that t is only changed appropriately. 
n(((^t V Op) A O ^9) ^" O ^0 ensures that t is lowered when p is asserted 
but q is not, and that t stays low as long as "g = False" holds. The formulae 
Di^tAQt — >■ O 9) and 0{tAQ^t ^ Op) ensure that the trigger is only raised 
when q is high and lowered only when p is high. Finally, the progress formula 
if'i ensures that the system will always eventually reach a state where it is no 
longer under an obligation to raise q. 



3.1.5 Stutter-Invariance 

Stuttering is a phenomenon connected with the repetition of states in the com- 
putations of an FDS. Two sequences a = aoaia2 . . . and b — t'0^1^2 • ■ ■ are said to 
be stutter-equivalent if there exist two infinite sequences of strictly increasing 
indices = io < Ji < ^2 < • • • and = jo < Ji < .J2 < ■ ■ ■ such that for every 
k> 0, the sequences 

flifeO-ifc + l ■ • • flifc+i-1 

and b.j,bj,+i...bj^^,-i 

are identical [69^. An LTL formula (p is stutter-invariant if for any two stutter- 
equivalent sequences a and b, either both a\=(p and b\=(p or both ai^ ip or bi^ (/jjj 
Informally, if a sequence satisfies a stutter-invariant formula, the same sequence 
with any element duplicated any number of times also satisfies the same formula. 

Stutter-invariance can be an important feature of specifications of an FDS. In a 
clock-triggered FDS, at each clock tick the values of the environment variables 
are read, and the next state is selected so that the environment variables have 
exactly these values. However, it might be the case that the values of the en- 
vironment variables have not changed from one clock tick to the next. This is 
called environment stuttering. 

In an asynchronous composition of several components, it is possible that one 
component proceeds more than once while all its peers as well as its environ- 
ment stay in the same state. The inputs are observed to be repeated. When the 



^That is, (p is satisfied by the union of stutter-equivalence classes. 
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components are executed on different processors or as different threads on the 
same processor, this situation occurs naturally from thread scheduling, different 
clock speeds and clock rate drift |44| . 

A clock-triggered FDS must therefore be invariant to environment stuttering, 
requiring the environment assumptions to be stutter-invariant. However, even 
if the system goals are stutter-invariant, the synthesis algorithm always tries to 
minimize system stuttering, since this would increase the state space. 

Peled and Wilke have shown that stutter-invariant properties in (future) LTL 
are exactly those that can be expressed without the next operator (i.e. the only 
allowed temporal operator is the until operator) and that stutter-invariance is 
decidable ([51], Lemma 2 and Corollary 6). Moreover, PSPACE methods exist 
for determining stutter invariance |70) . 

To obtain stutter-invariant environment assumptions, it is therefore sufficient 
to avoid the next operator. However, the synthesis method used in this thesis 
only supports the temporal operators always, eventually and next. Since the 
until operator is not supported, it is sometimes necessary to express formulae 
using the next operator. However, careful construction of these formulae might 
still render them expressible without the next operator. 

For example, consider the formula 

a{x ^ Oi^x ^ y)) 

expressing that x may only be cleared if y is asserted in the next state. This 
is a synthesizable property as it can be included in either ip^ or (p^ in a GR[ll 
specification. Moreover, it can be expressed without using the next operator 

by 

n(a; -^ xVy) <^ D{x -^ {xKyVOx)), 
and is therefore stutter-invariant. 



3.1.6 Specification Example 

In order to illustrate the specification concepts above, a toy example is pre- 
sented. A GR[1] specification is given that is synthesized by TuLiP into an FDS. 

The controller has one boolean environment variable x and two boolean system 
variables yi and j/2 ■ First the guarantee part of the specification is given. The 
system should start with both yi and y2 cleared and then respond to an input 
X by raising j/i: 

□ (a^^Oyi). 

This can be translated into a GR[1] formula by the method shown in Section 13.1.41 
Note that this will introduce another boolean system variable, called a trigger 



^Note that Di/J is equivalent to ^(TrueW-«/p) and therefore expressible without using Q- 
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that we denote by t in this example. We demand that yi may only be raised if 
2/2 is high. This is expressed by the guarantee 

To prevent ?;2 from being raised arbitrarily, x is required to be cleared as a 
prerequisite: 

□ (-2/2 A 02/2 ~> -^x). 

This specification consisting of just these three guarantees is unrealizable. This 
is because x might be asserted initially, requiring j/i to be raised eventually. But 
if the environment never clears x, then j/2 cannot be raised, which is required 
for yi to fulfill the response formula. 

In order to make the specification realizable, an assumption on the environment 
has to be included. Assuming that x is always cleared eventually turns out to 
be sufficiently strong. It is expressed by the progress formula 

The symmetric assumption that x will always be asserted eventually is included 
as well, because the environment should never just keep x low at all times: 

D<)x. 

Thus, the complete GR[1] specification is 

(p= (□Oa;A 

— >• 
(-2/1 A ^2/2 A 

□ (-2/1 A O 2/1 ^2/2) A 

□ (-2/2 A O 2/2 ->-a;)A 
Dix^Oyi)) 

This specification is synthesizable and gives rise to an FDS Ai^ with seven 
states, shown in Figure IXT] Recall that the extra system variable t has been 
introduced as a trigger to express the response property as a GR[1] formula. 

The initial states oi Ai^p are all those for which ^yi, ^y2 and ^t hold (com- 
pare with the translation of the response formula into a GR[1] formula). The 
restrictions on the rising edges of j/i and 2/2 can be verified by tracing the cor- 
responding arrows in the FDS. Thus n(— 2/1 A O2/1 — ^ 2/2) is verified by noting 
that qi — >■ (72 and qi — >■ q^ are the only transitions for which ^j/i A Q 2/i holds and 
that "2/2 = True " holds in go- □(— 2/1 A O2/1 ^ 2/2) can be similarly verified. 

The response property n(a; — > 2/i) is also satisfied, but only provided that both 
the environment assumptions D 2; and D ~^x holdo To see this, consider all 



*The guarantees are realizable given only DO ^2;, but the synthesis procedure also makes 
use of n a: to simplify M,p. 
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Figure 3.1: The FDS Ml^p synthesized from <p. States referred to in the text are 
boxed, and the valuations of the system and environment variables are given below. 



states in which "x = True" holds: In qq, "yi = True" holds, so the property 
is immediately satisfied. In (73, there is a transition to 94 which will satisfy the 
property. But there is also a self-transition that keeps "j/i = False" . However, 
since by D <} ~^x the environment has to clear x eventually, this self-transition 
cannot be taken infinitely many times, and so 94 must be entered eventually. 
In qo, the same assumption D ^x forces M^ to eventually enter qi, but there 
"yi — False" still holds. However, using both D ^x and 0()x, Ai^p must even- 
tually enter either (74 or qg, both satisfying "yi = True" and thus the response 
property holds. 



3.2 Specifying Distributed Systems 



As explained in Section 12.31 it is often necessary to synthesize a set of reactive 
systems that together satisfy a given global specification. Compositional synthe- 
sis requires both a global specification and an architecture. It has already been 
mentioned that compositional synthesis for almost all architectures is undecid- 
able. In this section we present principles that facilitate designing synthesizable 
local specifications and reasoning about the composition of the corresponding 
components in the architecture in order to establish that the global specification 
is met. 



We consider predecomposition, i.e. decomposing the global specification into 
several local specifications that satisfy the architecture before passing each of 
them to the synthesizer separately. The main challenge is to perform this de- 
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composition in such a way that the asynchronous composition of the FDS's 
synthesized from the local specifications satisfies the global specification. It 
is therefore necessary to have a mathematically sound way of reasoning about 
the asynchronous composition of the components in an architecture. Neglect- 
ing accuracy at this stage would render the efforts in synthesizing correct-by- 
construction controllers useless. 

Several attempts have been made at providing tools for the decomposition and 
reasoning about the composition of specifications. Misra and Chandy were 
among the first to reason about the composition of A/G specifications [BD]. 
Abadi and Lamport provide a formalism for reasoning about decomposing and 
composing A/G specifications in TLA [Tl[2]. In response to this, a purely syn- 
tactic formalism for LTL specifications was developed by Jonsson and Tsay [35] , 
providing a stronger composition rule. The work of Ozay et al. provides exam- 
ples of decomposing GR[1] specifications and how to reason about their compo- 
sitions [6711681. 



3.2.1 Composing Specifications 

Before principles for decomposing specifications can be stated, it is necessary 
to introduce the necessary framework to reason about their composition. We 
present the preconditions that have to be satisfied for a set of local specifications 
to satisfy a global specification. For notational convenience, these conditions 
are stated only for two components, but the extension to more components is 
straightforward. 

We present the Feedback Interconnection Refinement Rule stated by Ozay et 
al. [57] . It is a specific case of the Composition Theorem proved by Abadi and 
Lamport [2]. We employ this version because it uses LTL and GR[1] specifi- 
cations, although it is not the most general composition rule available. The 
proof of Abadi and Lamport's theorem covers several pages but the simplified 
version by Ozay et al. is straightforward to prove by induction on the length 
of the computations of the relevant FDS's ([57], see the proof of Proposition 
3). However, they do not take into account that the environment assumptions 
have to be stutter-invariant for the rule to hold for an asynchronous composi- 
tion. The Composition Theorem by Abadi and Lamport implicitly includes this 
assumption, since every property expressible in TLA is stutter-invariant. 



Architecture 

Let X and y be the global environment and system variables respectively, i.e. 
the variables that occur in the global specification ip. These sets are necessar- 
ily disjoint, because the environment variables X cannot be controlled by any 
component which controls 3^. 

The local environment and system variables of the synthesized components A^i 
and A^2 are then subsets of A" U 3^ so that even feedback between the compo- 
nents can be introduced (see Figure \T^ . Since all global system variables y 
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must be controlled by exactly one component, y is partitioned over the two 
components. Thus, the system variables oi A4i are J^i C y^ and the system 
variables of M2 are 3^2 = 3^\3^i- 

The environment variables of A^ 1 can consist of variables from the global en- 
vironment, but also from the system variables of A^2- Thus Xi C A" U 3^2- 
Symmetrically, X2 '^ X U yi. In Figure [TH we would have £1 = Xi\y2 and 
72,1 = '^1 n 3^2 and the symmetrical relations £2 = <-f2\3^i and 7i.2 — X2 oyi. 

This choice of variables defines the architecture for which we now develop the 
specification format and the hypotheses for the composition rule. 



Specification Format 

Suppose that a global specification ip^ — >■ (/;* is a GR[1] formula, where ip^ £ 
C(X) and (p'' € C{X U y). This is the specification that must be satisfied by 
the asynchronous composition of A^i and A^2- 

Let ifl G ^(£1) and ip2 G ^{£2) be stutter-invariant LTL formulae that will 
be part of the environment assumptions of jMi and jV{2 respectively. One of 
the conditions that these two formulae must satisfy is that any sequence a that 
satisfies the global environment assumptions also satisfies both ipl and (^| . Thus 

(PI) VctG V(A')°°.crN(^'= ^crNvsf Avs^. 

Note that A distributes over N, so when verifying this property it can alterna- 
tively be shown that N (/s*^ — > (/sf and N lys"^ — > (^2 hold individually. 

In an asynchronous composition, the transitions of the components AAi and 
M.2 may be triggered by two independent clocks and thus may react to changes 
in environment variables at different times. In particular, the transitions are 
not synchronized to the environment's changes of the variables it controls. It is 



therefore necessary for ip'i and (/Sj to be stutter invariant so that (PI) is sufficient 
in an asynchronous composition of A^i and A^2- 

The specifications ip\ and (/j| only allow to assume properties over the global 
environment variables X and not over the other component in the composi- 
tion. We therefore introduce the safety formulae (f>\ G C{Xi) and (t>2 G £(A2), 
called refinement formulae. They are added to the local specifications and 
so the environment assumptions of A^i and M.2 become 0^ A (/jf G C{Xi) and 
01 A (/5| G C{X2) respectively. 

The intuition behind separating these assumptions is that the refinements 4>l 
and (f)2 can also contain variables from 3^2 and 3^1 respectively, while fl and 
(^2 can only contain variables from A'i\3^2 and A'2\3'i respectively. The re- 
finements will thus make environment assumptions about a component's peers 
and will therefore somehow have to be satisfied by the system goals of the peers. 
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Let ifil G C{Xi U 3^1) and (^| G C{X2 U 3^2) be LTL formulae for the focal guar- 
antees. When these two specifications are satisfied by Mi and M2 respectively, 
they should together imply the global guarantee, that is 

(P2) Vcr e V(y)°° . a ^{ifl A (/5^) ^ cr 1= V9^ 

We now also refine the guarantee part of the local specifications by the safety 
formulae 0f £ C{Xi U 3^i) and 0| £ C{X2 U 3^2)- Thus the components Mi and 
M2 must satisfy their respective specifications: 

(P3) Mi^ Lp\ A (j)l ^ ipl A (j)l and 7^2 N (/7| A 0^ ^ (p| A (/)| 

Note again that (f>l, (/)|, <j>l and 0| are safety formulae and fl, 0f, (p2 and 0| 
are stutter-invariant. 



Circular Reasoning 

Including the system variables of the peer component in the refinement formulae 
gives rise to circular dependencies: Mi only has to guarantee 0^ if its environ- 
ment assumptions tpf A 0f are satisfied. This requires M2 to satisfy (/)| which 
in turn only has to be guaranteed if (/?2 A 4)2 is satisfied. The circularity comes 
from 02 requiring (pl to be satisfied by A^i (or symmetrically, (j^l requiring (^2 
to be satisfied by A^2). 

In order to establish sufficient conditions on the local specifications so that their 
composition satisfies the global specification, it is necessary to resolve this cir- 
cularity. This is done by imposing the appropriate conditions on the refinement 
formulae ^f , ^21 4'i ^^'i 4>2- We require that for any sequence a satisfying the 
global environment assumptions tp*^, if a prefix can be extended to satisfy the 
local guarantee part of one component, then the same prefix and the next el- 
ement in a still must be able to be extended to satisfy the local environment 
assumptions of the other component. 

It is important to require that the prefixes of sequences satisfying the global 
guarantees can be extended to satisfy the local guarantees, because the com- 
ponents must be prevented from entering a "one-way street" in their compu- 
tationso Consider for example a sequence S0S1S2 . . . — (j\^(p'^ and a prefix 
sqSi . . . Sn — o G pref{a) of a that can be extended to satisfy (/)f , the local 
guarantee refinement of the component Mi. That means that Mi can make a 
finite number of transitions in order to satisfy 0f . If Al 1 is currently in state g„ 
with V{qn) = Sn and it makes a transition qn -^pi Qn+i s.t. V{qn+i) = s^+i then 
the requirement that a extended by the element Sn+i in a can be extended to 
satisfy (pl simply means that by choosing to make this transition. Mi actually 
makes such a transition in the "right direction" . 

Also, the assumption must hold for one further element in the sequence, because 
it allows to prove properties about the transition from one state to the next in 



^This is comparable to entering a tree-subgraph of the graph-representation of the transi- 
tion relation, in which the leaf-nodes have no out-edges. Once a leaf of the tree is reached, no 
further transitions arc possible. 
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a component without needing to assume anything about the next state of its 
peers. This resolves the circular reasoning. The resolution in the proof is based 
on induction, so for the base case the first element in ct has to be able to be 
extended to satisfy the local guarantee parts of both components. 



Bad Prefixes and Closure 

The extensibility property introduced above can be formalized by defining the 
concept of bad prefixes, i.e. finite sequences that cannot be extended to satisfy 
a given formula. 



Definition 7. A finite sequence of states a E V{V)'^ is a bad prefix of an LTL 
formula ip E ^{V) iff for all infinite sequences a G V{V)°°, the concatenation 
aa does not satisfy f, i.e. aai^f. The set of bad prefixes of tp is denoted by 
badpref{(p). Then for a sequence a E V(y)+, 

a ^ badpref{ip) <^ 3a E V{V)°° .a\=ipAaE pref{a). 

D 

We call a formula pi stronger than another formula ip2 iS \= ipi — > (^2- 

Definition 8. For an LTL formula (p, its closure C{(p) is the strongest safety 
formula implied by it. That is, ^{(fi) is the strongest safety property s.t. N (^ ^• 

The sequences that satisfy €(</?) are exactly those sequences a s.t. each prefix 
of (7 is a prefix of some sequence satisfying (p. In other words, a satisfies C((p) 
iff any of its prefixes can be extended to an infinite sequence satisfying if. Note 
that 

(T N <L{(p) <^ V(T G pref (a) . a ^ badpref {(p) . 

Jonsson and Tsay give a syntactic definition of closure in LTL using past oper- 
ators [55] : 

€{ip) = D[3xE V{X) . mix ^x)A i{ip[x/x])] , 

where (^[S/rc] is the formula tp with the values x substituted for the variables x, 
and the existential quantifier 3 over finite sets V{X) is defined by 

{a,j)^3xEV{X).ip ^ (a,j)N V ip[x/x]. 

xev{x) 



The existential quantification in the definition of the closure is over all valua- 
tions of the variables in the environment variables X, or in other words, the free 
variables. This definition is used to prove the four-phase handshake protocol 
which is introduced below in Section [3.2.31 

Using the definition of bad prefixes, circular reasoning can be resolved if we 
impose the following restrictions on the refinement formulae: 
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(P4) For all sequences S0'Si'S2 ■ ■ ■ G V{X U y)°° that satisfy the global environ- 
ment assumptions ip'^, for any index n G No, if the prefix sqSi . . . s„ ^ 
hadprej {(j)\) then also the prefix sqSi • • • s»iS»i+i ^ badpref {(j)2)] similarly if 
the prefix sqSi . . . s„ ^ hadpref ((f)2) then also the prefix sqSi . . . s„Sn+i ^ 
hadpref {(j)\)] moreover, so ^ hadpref {(l)\) and so ^ badpref {(j)2) ■ 

Feedback Interconnection Refinement Rule 

We can now state the Feedback Interconnection Refinement Rule: 

Proposition 1. ([67 , Proposition 3) Given the architecture and the restrictions 
on the specifications outlined above, it holds that 



(P3) 



Mi^ (fil A (j)2 —> (fil A (pl 
M2 N (^2 ^ (?!)f -^ (^1 A 01 



given (PI), (P2), (P4). 



Proof sketch. Take a computation a E Cmi \m-2 of -^1 I -^2- If o'i^'ys'^, then 
the specification Lp'^ — > Lp'^ is automatically met. So we assume that the envi- 
ronment assumptions •^'^ are satisfied. Then, by|(PI) a also satisfies both local 



environment assumptions if>\ and (^2- Now (P4) ensures that the environment 
refinement formulae <f>\ and (/)| are satisfied for the initial state and both compo- 
nents can proceed infinitely from this initial state (because of the no bad prefix 
property). Therefore, for the initial state, (/sf A 4)\ and (^2 ^ 4>2 £^re satisfied. By 
|(P3)[ the local guarantees (/?f A (j)\ and ip\ A (jy^ are satisfied for the initial state 
as well. Then [(P2)] allows to conclude that ip'^ is satisfied by the initial state. 

Because of |(P4)[ the environment refinement formulae 0f and 0| are always 
satisfied for one further state than the system refinement formulae 01 and 0|. 
Since Lp\ and Lp2 are satisfied by a anyway, a also satisfies Lp\ A (/)f and (/jj A 02 > 
not just for the initial state. By a similar argument as for the initial state using 
[(P3)] and [(P2)| a satisfies ip" . U 



Verifying the Hypotheses 

In order to be able to use the Feedback Interconnection Refinement Rule, tech- 
niques are required to verify the hypotheses (P1)-(P4) that are required to 
deduce that the composition of the individually synthesized components satis- 
fies the global specification. 

The hypotheses give semantic conditions on the GR[1] specifications, which are 
harder to verify than syntactic conditions that are used e.g. in the work of Jon- 
sson and Tsay |36) . The latter approach is not adopted because it requires the 
introduction of past operators and existential quantification into the temporal 
logic, which are not supported by the synthesis procedure based on JTLV. 

Given lyjf, 1^2 j ^1 9'iid (p|, the properties |(P1)| and |(P2)| can be derived syntac- 
tically by using sequent calculus rules for LTL, see Section [2. 1.31 The property 
|(P3)|is satisfied by construction from synthesis. 
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Figure 3.2: Stuttering and Glitches 



Verifying I (P4) I in its full generality is more challenging. The simplest case is to 
just have Ni^^"^ A 0f — > 02 and \^(p'^ A (j)2 -^ 0ij which can also be verified by 
sequent calculus. 



3.2.2 Communication 

For a coordinated action of the components to satisfy the global specification, 
it is often necessary to enable some form of information exchange [12] . One way 
to handle communication is proposed by Kloetzer and Belta [40 [ HI] , but their 
approach does not involve the encoding of the communication protocols directly 
in LTL, allowing it to fit in the framework used in this thesis. 

An approach more appropriate for our purposes is to define communication 
protocols directly in LTL [TTJ [53] . The refinement of the local specifications by 
safety formulae that can contain system variables of the peer component allows 
some limited form of information exchange. 

However, in order to obtain reliable communication, it is required to introduce 
handshake protocols between the components. Their specification requires sys- 
tem variables to occur in the environment assumptions as well, which is not 
handled by the composition rule presented above. The stronger composition 
rules by Abadi and Lamport [5] and Jonsson and Tsay [3B] support this but 
have the disadvantage that they introduce operators into LTL that the synthe- 
sis does not handle. 

We will therefore identify where the Feedback Interconnection Refinement Rule 
fails to hold when system variables are allowed in the local environment as- 
sumptions and resolve them for the particular case of the four phase handshake 
protocol that is also used by Bloem et al. [llj . 



Glitches 

The symmetric situation to stuttering is when one FDS misses one or several 
transitions of its peers or the environment. When viewing shared variables 
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request: r e 

True 
acknowledgement: a False 



Figure 3.3: Four-Phase Handshake Protocol. 



as communication lines, then this may cause information to be lost and en- 
vironment assumptions to be violated, even though the environment behaves 
appropriately. This is illustrated in Figure [321 The FDS A^i is started in ^q 
while the environment is in state bq. The transition of A^i to ql follows after 
only one transition of the environment to ei, but A^i observes A^2 to directly 
transition from ^q to q^ . This could cause problems if qf needs to be observed 
in order to not violate the environment assumptions of A^i. Similarly, M2 ob- 
serves the environment to directly transition from ei to 63. 

These problems occur when the environment assumptions contain the next and 
the eventually operator. In particular, environment assumptions like 

where x and y are system and environment variables respectively, are not per- 
missible. No environment can guarantee that it will have asserted y the next 
time an FDS is observing it. This is because there can be a delay between x be- 
ing asserted and this information reaching the environment. The above formula 
is neither stutter nor glitch invariant. Also, 

D{x^Oy) 

is not glitch invariant, even though it is stutter invariant. The problem is that 
the environment may satisfy this assumption by asserting y for only one step 
and then clearing it again. This might be missed by an FDS that makes this 
environment assumption. 

It is therefore important to formulate specifications to be robust to such glitches. 
If a finite number of transitions arc missed, correct operation must still be 
guaranteed. 

3.2.3 The Four-Phase Handshake Protocol 

Consider the case of transmitting an integer i5 S [0,n) from a sender A4s to 
a receiver Mr. The sender controls a request signal r € [£,n). If r = e, this 
indicates that no data should be transmitted. If r ^ e, then the data that is 
to be transmitted is <5 = r. The receiver controls a boolean acknowledgement 
signal a. The request signal r appears as an environment variable r G [e, n) 
at the receiver. Similarly, the acknowledgement signal a appears as a boolean 
environment variable a at the sender. 
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Figure 3.4: Composition of the sender Ms and receiver Mr. 



Thus, the architecture that contains the sender Ms and the receiver Mr can 
be visuahzed as in Figure 13.41 Comparing this with the generic composite archi- 
tecture in Figure [23] yields £s = {t}, Ss = 0, Tr,s = {r}, Ts,r = {a}, £r = 
and Sr ~ {s}. Thus the composite FDS Ms \Mr has the environment vari- 
ables X — {t} and the system variables y — {a, r, s}. When using the protocol 
in a larger specification, the trigger t is likely to also be a system variable of A^5. 

The four-phase handshake protocol can be informally described as follows. The 
sender Ms initiates a transfer by setting r = S. Once Mr detects this, it may 
use the transferred data somehow, and then raises a. When Ms sees that a has 
been asserted, it resets r = e. After Mr^ detects this, it clears a, completing 
the transmission of S. This is outlined in Figure IX^ 



Sender Specification 

The sender assumes one liveness and two safety properties about the receiver. 
It is assumed that if the request is reset, the acknowledgement will be cleared 
eventually, allowing for a new request to be made: 

I n(r = e^O-a)- 

The assumed safety properties assert that the acknowledgement signal does not 
change in a way that is not allowed by the protocol. There is no acknowledge- 
ment without a request: 

II n(^aAOa^'' 7^ e)- 

Also, the acknowledgement may only be cleared if the request has been reset 
before: 

III aiaAQ^a-^ r = e). 

The sender guarantees three safety properties. No liveness property is guaran- 
teed, because the sender may just remain idle. However, a system using this 
protocol will have to contain a liveness property that implicitly guarantees live- 
ness in the protocol. Also, as long as the request is not acknowledged, it must 
stay at the same value: 

VII /\ D{^aAr = i^O{r = i)). 

ie[0,n) 

The request may only be reset to e: 

VIII /\ n{r = iAO{r^i)^0{r = e)). 

i<£[0,n) 
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Lastly, the sender responds to an acknowledgement by resetting the request: 

IX D{a^O{r = e)). 

Note that this last guarantee also ensures that the sender may only initiate a 
transmission if the acknowledgement signal is low. This could be expressed by 
the additional guarantee D{r = e A 0(^ 7^ ^) ^' ~^'^)j but clearly this is already 
implied by IX. 



Receiver Specification 

On the receiver side, one liveness and two safety assumptions are made. The 
receiver assumes that each acknowledgement eventually results in the request 
to be cleared: 

IV n(a^O(r = e)). 

It also assumes that the request reacts appropriately to the acknowledgement. 
Similar to guarantee VII, no transmission is initiated if the acknowledgement is 
still high: 

V n(r = eA0(^7^e) ^ ^a). 

Also, the request may only be cleared if it has been acknowledged: 

VI n(r 7^eA0(^ = e) ^a)- 

The receiver guarantees that each request will be acknowledged: 

XI n(r^e^Oa)- 

And it guarantees that the resetting of the request results in the acknowledge- 
ment to be cleared: 

XII D{r = e^0^a). 

Moreover, the acknowledgement may only be raised on a request: 

XIII n(-aA0a^^7^e)- 

Lastly, the acknowledgement may not be cleared unless the request is reset: 

XIV aiaAQ^a^r^e). 

Reliability of the Four- Way Handshake Protocol 

It now remains to show that the four-phase protocol reliably transmits data 
from the sender to the receiver. To show this, we introduce a boolean variable t 
into the environment variables of the sender Ais, which will act as a "trigger" 
to a message being sent. The data will just be a single constant 6 G [0,n). 
Similarly, introduce an integer variable s € [0,n) into the system variables of 
the receiver, which will act as a "sink" where the sent data will be stored for 
later use. We add the response property 

X D{t^0{r = 5)) 
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to the guarantees of the sender, which ensures that the data wih eventually be 
sent, once the transfer has been triggered by "t = True" . Similarly, the response 
property 

XV n{r = 6^ 0(s = S)) 

will be added to the guarantees of the receiver. Note that while in XV the even- 
tually operator might be substituted by a next operator, this cannot be done in 
X, since changing r is restricted by a, which is not controlled by Ms- 

The full local specifications are shown in Figure [^3 The global specification 
is n(i — 7> 0(s = ^)), requiring that once a transmission is triggered by t being 
asserted, the data S eventually arrives correctly at the sink s. We thus want to 
prove the following: 

Proposition 2. liMs'Fipg — ^ ipg and Mr\=(p'ji -^ (p% then A^5 | Mn^nit -^ 

Proof. We make use of the Composition Theorem of Abadi and Lamport ([2], 
Theorem 3), which in our particular case is: 

(^3) N^|Aypj;^Dft-^0(g^^)) 

[Ms^ip's ^ ^'s) A{Mr^^'j^^ ^jj) ^ Mi\M2^D{t ^ Oi-s = S)) ^ ■ ' 

Note that we only use a nesting depth of the next operator of one in the GR[1] 
specifications, so the explicit translation to TLA is omitted. For the closure 
required for the Composition Theorem, the above LTL definition by Jonsson 
and Tsay will be used. 

Precondition (A3) can be established by taking X 0{t -^ 0(^ = <^)) and XV 
\3{r = (5 — > (){s = 6)). From these specifications it follows that 0{t — > 0(s = S)). 
This is intuitively clear, but can also established by a sequent calculus proof. 

For the preconditions (Al) and (A2), consider the closure of (pg, which is 
n(3t, a.B(i = i A a = a) A ^{fg[t/t][a/a])) and the closure of 93^, which is 
n(3f . ■(f — r) A ^ifRir/r])). We consider the individual cases for values of i, 
a and r to deal with the existential quantification, which, by definition, is just 
a shorthand for disjunction. 

Note that \=D^D(p ^^ Dip and ^DUf ^ Of ioT any LTL formula ip, which 
helps to simplify the closures of the formulae we are considering. 

Case 1. i = True, a = True: 

Evaluating the conjuncts for these valuations yields nO(^ = ^) from IX and 
DOi''' — S) from X. These two formulae can never hold together and thus in this 
case the closure of 1^9^ is simply false. As false implies everything, both (Al) 
and (A2) hold in this case. 
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IV n(a^O(r = e))A 
Mi^Nl V n(r = eA0(^7^e)^-a)A 
VI a{r ^€AO{r = €)^ a) 



I VII n(r = e A 0(^ 7^ e) ^ -a) A 

VII A^e[o,„)n(-«Ar = «^0('^ 

VIII A.e[o.„)n(^-«AO('^^*)- 

IX n(a->0(^ = e))A 

V X n(t -> o(r = 5)) 



= 0)A 

0(^ = 



6)) A 



/ XI n(r ^ e ^ O a) A 

XII n(r = e ^ O -a) A 

XIII n(^a A0a^r7^e)A 

XIV n(aAO^a^^ = e)A 
V XV U{r ^ 5 ^ 0{s = 5)) 



Figure 3.5: Specification of tiie four-pliase iiandsliake protocol. 
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Case 2. t — True, a — False, r — e: 

Here the conjunct resulting from X is nO('' = ^)i but we also have ^{r = e) 
due to the existential quantification. Thus, again the antecedent is false and so 
both (Al) and (A2) are implied. 

Case 3. i ~ True, a — False, f — S: 

Evaluating the conjuncts in the closures for these variables yields the conjunct 
nO(s = 6) for XV. Moreover, the conjuncts 0{t — True), n(a ~ False) and 
n(r = S) are in the closures from the existential quantification. 

For (Al) we need to deduce I- VI from these conjuncts. I and VI follow from 
\3{r = S) and II~V follow from \3{a = False). 

For (A2) we need to verify the individual terms of the closure of n(i -^ (){s = 
S)), which is D{3t . ■(i = i) A ♦ n(t ^ 0(s = S))). 

In order to resolve the existential quantification, we again consider both truth 
values of i. However, since we are now proving the closure as a consequent, we 
only need to exploit one value of i for which the closure of n(t — > 0(s = (5)) is 
implied by the antecedents. 

Let t = True. Then the closure becomes D M{t = True) A D ♦ D 0(s = S). The 
first conjunct follows simply from n(i = True) from the closure of ipg. The 
second conjunct follows from XV, i.e. D 0("S = S). 

Case 4. t ~ True, f ^ e and f ^ 5: 

Evaluating the conjuncts for these variables yields the conjunctsn(a V C)^a) 
from XIII and D{^a V 0<3^) from XIV. These two conjuncts already yield a 
contradiction, and so (Al) and (A2) are both satisfied. 

Case 5. i = False, a — True, f — e: 

The conjunct in the closure resulting from XII is D O ~^'^- This stands in con- 
tradiction with the conjunct \3{a = True) from the existential quantification. 
Thus both (Al) and (A2) are satisfied. 

Case 6. f — False, a — True, f ^ e: 

The conjunct in the closure resulting from X is nO(^ = s)j but the existential 
quantification requires \3{r ^ e). This leads to an immediate contradiction, so 
both (Al) and (A2) are satisfied. 

Case 7.1= False, a = False, f = e: 

To prove (Al) we again need to be able to deduce I- VI from the conjuncts of 
the closure. I-IV follow from \3{a = False) while V and VI follow from \3{r = e). 
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For (_A2) consider again the closure C:(n(t -)■ 0(s = S)) = n(3i.B(i = t) A 
♦ n(t — >■ 0(s = f^)))- By taking i = False, this closure is implied simply by 
n(i = False). 

Case 8. i = False, a — False, f = S: 

For the preconditions (Al) and (A2) the conjuncts from the existential quantifi- 
cation are sufficient: I-V follow from n(a = False) and VI follows from \3{r = S). 
Moreover, in the same way as in Case 6, (A2) follows from \3{t = False). 

This covers all cases and so the preconditions (Al) and (A2) have been estab- 
lished. The result follows from the Composition Theorem p.ip stated at the 
beginning of this proof. D 

Note that we had to use (j3.ip . a stronger result than the Feedback Interconnec- 
tion Refinement Rule in order to be able to incorporate the system variables in 
the environment assumptions, and to include liveness formulae in the specifica- 
tions. 

When using the four-phase handshake protocol in the form just proved several 
things should be noted. It is always possible to use weaker assumptions, as long 
as the specification remains synthesizable. In particular, omitting conjuncts in 
(fig or i^Ij does not change the correctness of the protocol. However, the guaran- 
tees i^g and i^Ij must be provided in a specification. They need not occur in the 
same syntactic form, but can be strengthened to an arbitrary degree without 
affecting correctness of the protocol. 
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Chapter 4 

Searching 



One of the main challenges in SAR is to locate the targets that need to be 
rescued. In order to avoid ambiguities, the physical environment of the robot, 
such as a building in USAR or a landscape in WiSAR, is referred to as topol- 
ogy. The controllers are specified and synthesized with a two-player game in 
mind, which then can be thought of as taking place on a graph representing the 
topology. Assuming that a SAR robot can detect the presence of a target if it 
is in the same vertex of the graph-representation of the topology, the problem 
is to detect the vertex the target is in. 

The solution depends on the capabilities of the robots and the targets, as well 
as the amount of information they have. Here we differentiate searching for a 
stationary and a moving target. When the target is stationary, it is sufficient to 
ensure that each vertex in the graph is eventually visited by at least one robot |^ 
When the target can move, we formulate a pursuit-evasion game, in which an 
evader (the target) tries to avoid being captured by one or more pursuers (the 
robots). The controller specifications are developed from the winning strategies 
for the cops of this game. 



4.1 Preliminaries 

Before presenting the search strategies for the different scenarios, we make pre- 
cise the concept of the graph representation of the topology and the way sensors 
are incorporated in our specification framework from Section [S] 



4.1.1 Graph Representation of the Topology 

In order to reason about the movement of the robots in an SAR task, the topol- 
ogy must be represented internally in a way that admits LTL specifications 
about the positions of the robots. The topology is partitioned into discrete 
"cells" that are typically polygonal shapes. The robots move from one cell 



^This can be extended to require any number of robots to visit the vertex at the same 
time. 
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V4) iV3 



Figure 4.1: Graph representing a topology with five cells. Each vertex stands for a 
cell and the arrows are the allowable moves between cells, which can be thought of 
e.g. as doors or corridors between rooms in a building. The graph implicitly contains 
a self-loop for each vertex. 



into another cell using continuous control, which is discussed e.g. in the work 
of Kloetzer and Belta gO], Kress-Gazit et al. [IJ and Topcu et al. [90]. Af- 
ter subdividing the topology into, say n such cells {Co, Ci, . . . , C„_i}, we are 
only concerned with controlling the discrete moves between cells, represented by 
changing the integer system variable celllD G [0,n) of the robot, which thusly 
holds its position. 

The changes of celllD are constrained by the topology, which can be represented 
by a directed graph G = {Vq, Eg). Each vertex in Vg = {vq, vi,. . . , Vn-i} cor- 
responds to a cell. The possible transitions between the cells are the edges Eg- 
An edge e going from the vertex u G Vg to the vertex v G Vg is an ordered pair 
(w, w) G V(3 X Vg. The edge e = {u, v) is an in-edge of v and an out-edge of u. 



Definition 9. A path is a sequence of vertices p — v^v^ . . . w'"^ over Vg s.t. 
(w%w'+^) G Eg is an edge for all indices « G [0,/ — 1). A simple path is a 
path with unique vertices, i.e. it contains no cycles. The i*'' element of the 
path p is also denoted by p{i) — w*, and we say that p is a path from p{0) to 
Pil~l)=p{\p\-1). a 

Definition 10. A graph G — {Vg, Eg) is strongly connected iff there exists 
a path from every vertex ii G Vg to every other vertex u G Vg. Denote the set 
of all strongly connected directed graphs with n vertices by 6„. D 

We require the graph G representing the topology to be strongly connected, 
that is, it is possible to get from every vertex to any other vertex of the graph. 
If a graph is not strongly connected, there may be cells that the robots are 
not able to access, depending on their initial positions. Targets located in such 
inaccessible cells could never be found with any strategy. 

The constraints on celllD are incorporated in the guarantee part of a robot's 
GR[1] specification. Consider for example the graph shown in Figure ITTl which 
is strongly connected and therefore qualifies as a valid basis for synthesis. A 
robot is always allowed to stay at a vertex, so the self loops are included im- 
plicitly. For notational convenience, we use the boolean variables Xi instead 
of explicitly writing celllD — i, i.e. Xi ~ True <=> celllD = i. Further let 
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n = \Vc\ be the number of vertices in G. Then, for the graph in Figure l4Jl the 
corresponding specification is 

fG = n(Xo ^ 0(^0 V Xi V X3))A 
n(Xi^O(^oVXi))A 

□ (^2^O(^0VX2VX4))A 
□(^3^0(^lVX2VX3))A 
n(X4^0(^2VX4))A 

□( V (^'^^ A ^^*))' 

he[0,n) i£lO,n)\{h} 

where the last hue is a mutual exclusion formula, preventing the robot to think 
that it is in two cells at the same time. This ensures that D{cellID = i -r-> X^). 



4.1.2 Generating Random Strongly Connected Graphs 

The methods developed in this chapter are tested on randomly generated graphs. 
We use the Erdos-Renyi Model in order to generate random directed graphs that 
are strongly connected ^^. 

For this purpose, we represent a graph G = {Vg,Eg) with n vertices Vg — 
{t!o,fi, . ■ . ,Vn-i} by its adjacency matrix Adj{G) e Z" x Z", where the i, j"^ 
entry of Adj{G) is nonzero exactly if there is an edge {vi,Vj) £ Eg from Vi to 
Vj. We require that a graph contains all self-loops, so the diagonal of Adj{G) 
for any graph G that we are considering contains only nonzero elements. Since 
any nonzero entry in Adj{G) represents an edge, the adjacency matric can also 
be used to store state information of edges by using different nonzero values. 
This is used for example for the moving target search, see Section l4.4.1l 

To generate a random graph G with n vertices, we select a constant P such that 

P> ' 



1 

Further, let X be a continuous random variable that is uniformly distributed 
over the range {a; | < a; < 1} C R. Next, we draw one sample for each pair 
of vertices from X, yielding the n'^ samples ei^i, ei_2, ■ • ■ , ei^„, 62,1, 62,2, • ■ • , e„^„. 
For all i and j, if Cij < P then let the i,j^^ element of Adj{G) be one and zero 
otherwise. Thus, a matrix of ones and zeros is generated that defines the graph 
G. 

With this choice of P. the resulting graph G almost surely contains one "giant" 
component, i.e. a subset of vertices covering almost the entire graph in which 
each vertex is reachable by a path from each other vertex in the same set. How- 
ever, we still need to check, whether G is indeed a strongly connected graph. 
This can be done by self-multiplying Adj{G) n times and testing whether or not 
all elements in Adj{G) are nonzero. The process of generating a random graph 
is repeated until this test yields a positive result, confirming that the graph is 
strongly connected. 
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4.1.3 Sensors 

So far, the input variables of an FDS were considered to be controlled by an 
abstract environment. When an FDS is executed on a microprocessor, the input 
variables are abstractions e.g. from inputs received from sensors or data transfer 
lines connected to the processor. For example, a boolean environment variable 
may be the abstraction of the input received from a sensor detecting the state 
of a switch. 

When considering an FDS to be the controller of a robot that moves on a graph 
G, sensors can be differentiated between gathering information from the entire 
graph or just a subgraph of G. In the former case we speak of global infor- 
mation, while information from a subgraph in the vicinity of the robot is called 
local. In the extreme case, a robot may only obtain sensor inputs from the 
vertex it is on. 

Thus, sensor inputs, e.g. represented by an environment variable s, depends 
on the system variable celllD. However, the robot does not know about this 
dependency. Therefore, when simulating the FDS, we must ensure that the 
state of the graph is maintained globally, but only the appropriate local in- 
formation is available to the robot by changing s accordingly. This is further 
discussed in Section 14.5.21 and is implemented through connectors as explained 
in Section lS.l.ll 



4.2 Stationary Target Search 

In an USAR application, taking place for example in a collapsed building, the 
targets are usually assumed to be stationary, and thus the search only involves 
visiting each vertex by a robot until the target is detected. A global specification 
therefore requires that once a vertex contains a target, it is eventually visited by 
at least one robot. Here we present the concept of stationary target search by 
considering only a single target at a time in the graph. In the implementation 
presented in Scction f5.il several targets can be rescued at the same time. 



4.2.1 Global Specifications 

Let G = {VgtEc) be a directed graph with n = \Vg\ vertices. In order to 
formulate the global specification, we introduce the global integer environment 
variable is [e, ?i), which indicates whether and where a target needs to be res- 
cued, lit — e then no target is in the graph, but lit ^ e then a target is located 
on vertex wj, i.e. the vertex with index t. This represents the actual state of the 
target, but the robots have no direct information about the value of t. Rather, 
the robots are equipped with sensors that provide local information about the 
vertex the robot is currently on. Thus the robot only sees the value of t when 
it is on the vertex vt- 

Assume there are m robots {R[)^ Ri, . . . , i?m-i} searching for the targets, each 
with a unique index j € [0,m). The position of robot Rj is controlled via the 
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system variable celllDj G [0, n). For notational convenience, we use the boolean 
variable Xf instead of explicitly writing celllDj = i. 

The main global system goal therefore can be stated as follows: 

^'= A ait = ^^Oi V n))- (4.1) 

ie[0,n) jG[0,m) 

This expresses that once a target is at vertex Vi, at least one robot will find it, 
i.e. at least one robot will eventually move to the vertex Vi. In order for this to 
be realizable, we have to at least assume that the target stays at the vertex until 
it is discovered. This is the stationarity assumption, and it can be expressed 
by the global environment assumption 

'p''= A n(t = zAO(M0^ V ^/)' 

ie[0.n) je[0.,m) 

which says that in order for vt to change from a value that is not e, at least one 
robot has to be at the target's vertex. A different way of expressing the global 
system goal is 

which makes the actions required for the target at t to be rescued implicit. In 
order for <^* to be realizable, the environment assumptions must indicate how t 
reacts to the actions for the robots, i.e. how the system variables can be changed 
in order to clear t. For example, t can be cleared if a robot moves to the vertex 
Vt, which is expressed by the environment assumption 

ie[0,n) je[0,m) 

Note that the two specifications here might not be synthesizable and not even 
realizable. They are merely shown to illustrate the principle behind specifying 
stationary target search globally. 



4.2.2 Compositional Specifications 

The specification ip'^ — >■ ip''^ (or (p'^ — >■ (p''') might not be complete or realizable, 
but it expresses the main idea behind globally specifying a distributed search 
in a graph. If a synthesis algorithm existed for general compositional synthesis, 
this specification could directly be used to synthesise a reactive controller for 
each robot in the architecture, s.t. together the robots would implement the 
global specification. However, since no such algorithm exists, the specification 
must be decomposed manually. 



Minimal Specification 

Each robot can have a simple local specification 



A °o^^ 

ie[0,n) 
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stated here for the robot Rj. Note that the robot knows nothing about the 
location t of the target and no sensor information is used. This way of searching 
assumes that the target reacts automatically to the robot being in the same 
cell by becoming rescued. Note however that in order to actively engage in the 
rescue of a target, the robot needs to react to a sensor input that indicates that 
it is in the target's cell. 

In this specification, there is no coordination between the robots, and so the 
search might be inefficient. However, we are not so much concerned about ef- 
ficiency of our controllers as with their correctness o Synthesizing a controller 
from this specification would indeed satisfy the global specification given above. 
However, when not one, but several robots are required to find a target, a differ- 
ent approach is needed. With stationary targets this is not hard to implement, 
since a robot can just stay with the target until a second robot arrives, requiring 
the robot to have information from a sensor that it is in the target's cell. 



Circular Search 

Another approach is to explicitly encode the paths that the robots have to take 
through the graph in order to visit each vertex at least once. This again does not 
allow for coordination between the robots. It has however one decisive advantage 
over the previous approach: It is explicitly known to the robot when the search 
is finished. In the previous approach, only the finiteness of the state space of the 
synthesized FDS induces a bound on the time to complete searching the grapho 

The paths are extracted from the graph by finding a shortest cycle that contains 
all vertices, which can be done by the algorithm FindCyle in Table ITTl The 
algorithm is provided with a starting vertex u and returns a shortest path p that 
starts at u and ends at a vertex v, such that there exists an edge {v,u) G Eq 
and p contains each vertex in Vg at least once. 

In the specification, the robot can explicitly be instructed to follow the path 
p returned by FindCycle. Since the cycle formed by the edges connecting 
the vertices in p might not be HamiltoniarO, it is not sufficient to just encode 
this with guarantees such as D{X-',g. -^ Q ^"'(i))- This is because some vertices 
might need to be visited several times and at such vertices the choice of the next 
vertex depends on the current position in the path. By introducing a counter 
system variable c G [0, \p\) and letting the robot visit the elements on the path 
in order it is possible to keep track of the elements in p already visited. 

The search is started with the counter at zero and the robot being at p{0) = u: 

X^' A c = 0. 

p(0) 



^Arbitrary efficiency bounds cannot be provided in GR[1] specifications that have a limited 
nesting depth of the next operator Q ^^id lack the bounded until operator U— . In fact, the 
allowed nesting depth of Q is j^^t one in GR[1] specifications. 

^We assume that the topology of the environment does not change, so it is a valid solution 
to explicitly encode a path for the robot. However, if the topology is unknown or changing, 
this approach is no longer appropriate. 

*A cycle is Hamiltonian if it contains all vertices of a graph exactly once. 
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FindCycle (u) 

paths = [[u\] 
while True do 

extendedPaths = [] 
for p in paths do 

if p does not contain aU vertices in Vg or p does not end in u then 
newpaths — ExtendByOne(p) 
append newpaths to extendedpaths 
else 

take away the last element of p (i.e. p no longer ends in u) 
return p 
paths = extendedpaths 

ExtendByOne (p) 

if p is empty return 

paths = [] 
for u e Vg do 

if {p{\p\ - l),v) e Eg then 

newpath — p extended with v 

append newpath to paths 
return paths 



Table 4.1: Algorithm to find cycles containing all vertices in a graph. Calling Find- 
Cycle(M) on some starting vertex u £ Vg yields a list of vertices p that induces a 
cycle in G. Assuming list operations to be 0(1), the runtime complexity of this naive 
implementation of FindCycle is 0{n ■ n!) for dense graphs, and 0{n*) for sparse 
graphs with 0{\Eg\) "^ 0{\Vg\)- 
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Note that X-',^^ is a synonym for celllDj — p(0), so all variables Xl with i ^ p(0) 
necessarily valuate to "False" . The counter is restricted to only increase, unless 
it has to be reset to zero in order to loop when the path is completed. Define 
nextval{"f) = (7 + 1 + |p|) mod \p\ to be the next value of the counter when the 
current value is 7, where mod is the infix operator for the remainder of integer 
division. Then this rule can be written as: 

□( V (c = 7A0(c= ?iea;fm/(7)))). (4.2) 

76[0,|p|) 

The robot moves along the path, increasing the counter by one each step: 

A □(^p(,)Ac = 7^0(^^(„,,,™,(,))Ac=neztW(7))). (4.3) 

7e[o,|p|) 

Both (|4.2p and (|4.3p are required in a complete specification: (|4.2p prevents 
the counter to change to a value not corresponding to a valid position in the 
path (safety property), which would allow the robot to just remain at the same 
vertex. (j4.3|) is required for the robot to make any progress at all (liveness 
property), forcing the counter to increase. 

This way of searching a graph is used in the implementation of moving target 
search, since there it is necessary that the robot knows when the search is fin- 
ished, which is indicated by c = |p| — 1. A full specification of this type of search 
is given in Section 15.21 when searching for particular vertices in the topology. 



Other Search Methods 

Searching a graph can also be implemented as a depth-first-search or as another 
exploration algorithm. The specification of such algorithms is not straightfor- 
ward, but can be done using counters and storing information in the vertices 
similar to the approach presented in Section I4.5l under the heading "Global Stor- 
age" , which ensures that the state space does not explode. 

A depth-first search can handle an unknown environment topology of finite ex- 
tent, if the vertices are able to store information for the robot and provide the 
robot with information of its neighboring vertices. However, synthesis from an 
LTL specification might not be the best approach to implement such an algo- 
rithm that has already been proved to work in a standard implementation. 



4.3 Moving Target Search 

When the target is moving, such as in a WiSAR application, it is no longer suf- 
ficient to visit each vertex eventually, like in the stationary target search. For 
most topologies, a fixed number of robots might never be able to find a moving 
target. Consider for example the situation in Figure W?^ where a single robot 
(•) is trying to find a moving target (o) by moving on the same vertex in the 
topology. The target can evade the robot by always going to the opposite vertex 
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(a) Initial configuration (b) During the transition (c) Final configuration 

Figure 4.2: The target (o) evading the SAR robot (•). 



at the same time as the robot moves. If the target knows the robot's strategy, 
it can always evade the robot. 

It is therefore necessary to implement a search strategy that ensures that even 
a moving target cannot escape the robots. This problem has been considered 
before and successfully implemented, for example in the work of Vidal et al. [88] . 
These implementations use probabilistic methods to find the target; we use a 
different approach in this thesis, and consider the problem of finding a winning 
strategy for a game of the robots against the targets on the graph representing 
the topology. 



4.3.1 Game Theoretic Approach 

Trying to find a moving target can be seen as a form of a pursuit-evasion 
game in which the target tries to evade its pursuers, the SAR robots. The 
objective of the game in its original formulation is to find the minimum number 
of robots necessary to guarantee that the target is eventually found. Depending 
on what moves are allowed for the robots and the targets, the robots must im- 
plement different strategies in order to reliably find the target. A recent survey 
by Chung et al. provides a taxonomy of properties for pursuit-evasion games [171. 



Cops and Robbers Game 

We consider a particular form of pursuit-evasion game called the cops and 
robbers game first introduced by Nowakowski and Winkler [66] . A number of 
cops and robbers take turns in moving on a directed graph by traversing edges 
from vertex to vertex. A cop captures a robber if they find themselves on the 
same vertex or edge. Cops can move one edge at a time, but the robbers can 
move with infinite speed, i.e. in each turn they can move along any number of 
edges. However, they cannot pass through vertices that are occupied by cops. 
To align with standard formulations, a robber may hide either on a vertex or 
on an edge. 

The cops win the game if the robber is eventually captured, while the cops lose 
the game if any of the robbers are able to evade the cops forever. The robbers 
are supposed to be adverse and always choose the worst possible move against 
the cops. They also know exactly where the cops are and their strategies, while 
the cops have no information on the position or strategy of a robber, unless it is 
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captured. The game is considered as a two-player game between ^, the central 
coordinating authority of the cops against the adverse robbers, modelled as a 
single player ^. 

A strategy for the cops defines the moves of the cops on the graph depending 
on the observations about the targets. A winning strategy for the cops is a 
strategy that guarantees that all robbers are found in a finite number of moves. 
The game is solved by finding the minimum number of cops for which a win- 
ning strategy exists for a given graph. 

Note that the terms robot, cop and pursuer can be used interchangeably, as is 
the case for target, robber and evader. Unless the context demands otherwise, 
we use "robot" and "target" throughout the rest of this section. 



Cop Numbers 

Most graphs require more than one robot to capture the targets, see for example 
Figure IT^ This concept is formalized by introducing the cop number c{G) 
of a directed graph G, which is the minimal number of robots required to win, 
regardless of the initial positions of robots and targets. For example, the graph 
in Figure ITT] has a cop number of 3. 

Immediately the question arises how to compute c{G) for a given graph. An- 
other problem is to give sufficient properties for a graph G so that c{G) has a 
fixed value. In this thesis we are not concerned with answering these questions 
but rather how to find a winning strategy for c{G) robots for a class of graphs 
that is as general as possible. Such a winning strategy clearly exists for c{G) 
robots by definition. 



4.3.2 Computational Considerations 

For general graphs and if the robots have no information about the positions 
of the targets, finding the cop number is NP-complete ([I3]j Figure 1). Even 
when both robots and targets have complete information about the positions 
of all robots and targets, computing c{G) in an undirected graph, which is a 
simpler problem than the one we are considering here, is EXPTIME-complete 
([20], Theorem 3). 

It was shown before that the synthesis of a GR[1] specification ip can be done in 
polynomial time in the size of ip. However, we do not try here to solve an NP- 
complete problem by a polynomial time algorithm. When formulating a GR[1] 
specification tp for a winning strategy, (p must explicitly contain the system 
variables that control the robots, i.e. celllDj for all j. Therefore, the number 
of robots that is available to pursue the targets is already explicitly encoded in ip. 

With such a specification, GR[1] synthesis merely decides whether a given num- 
ber of robots is sufficient to win the game. However, this does not mean that the 
cops and robbers game is solved, which consists in finding c{G). This must be 
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done at the time of formulating the specification, because the system variables 
must be able to independently control at least c{G) robots. 

From this discussion we conclude that the cops and robbers game cannot be 
solved by GR[1] synthesis: An NP-complete problem cannot be solved by the 
polynomial time algorithm for GR[1] synthesis. However, realizability of a spec- 
ification (/J of a winning strategy that explicitly includes the number of robots, 
can be decided by GR[1] synthesis. This is shown constructively in Section [F?^ 
by synthesizing controllers implementing a winning strategy. 

Since GR[1] synthesis cannot be used to find c{G) and a GR[1] specification 
must have the number of robots encoded explicitly, we assume that the cop 
number c{G) is provided alongside a graph G. 



4.4 Moving Target Search Strategies 

Instead of solving the cops and robbers game, we are interested in finding win- 
ning strategies for a given set of m robots {i?o, ^i, ■ • • , Rm-i}- Clearly, no such 
strategy exists if m < c{G). We first categorize the winning strategies given 
that a central authority "^ can directly control the moves of all robots, called 
globally coordinated winning strategies. 

Thus the player "^ implements its strategy as an FDS M-^, which is specified by 
a GR[1] specification (p<^. The environment variables of Ai-^ are controlled by 
the player ^. However, no FDS implementation Ai^g of the targets' strategy 
is synthesized. The targets are simply assumed to always perform the worst 
possible moves for the robots. 

The central authority '^ controls the system variables celllDj for all j. This is 
the standard formulation found in the literature. However, we go on to iden- 
tify globally coordinated winning strategies that can also be specified by sev- 
eral GR[1] specifications that are synthesized into a set of FDS's that together 
implement the globally coordinated strategy. This corresponds to reformulat- 
ing the two-player cops and robbers game into a game where several robots 
'^i,'^2, ■ • ■ ,'^m play against the adverse targets ^. The winning strategies of 
the robots are based on local information in the graph only, and they must ne- 
gotiate with each other in order to cooperate or share information. Therefore, 
such strategies are referred to as locally coordinated winning strategies. 

Note that the requirement to provide sufficiently many robots means that the 
cop number must be known at specification time. It turns out, that the cop 
number is not even required to be included in the local specifications, but is 
used only to build the architecture for sufiiciently many robots. 
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4.4.1 The State of a Graph 

We define the state of a graph to indicate to the robots whether the target can 
be said with certainty to not be on a particular edge or vertex. If the target 
cannot be on an edge, then the edge is contaminated, and the same notion is 
introduced for vertices and graphs in the foUowing definitions: 

Definition 11. An edge e g Eq in a graph G — {Vg,Eg) can either be con- 
taminated or cleared. InitiaUy, all edges of the graph are contaminated. A 
contaminated edge e = (u, v) from u to w can be cleared by a robot either by 
placing a guard robot on u and sliding down the edge from u to f with another 
robot, or if all in-edges of u are already cleared by simply sliding down the edge 
from u to w with a robot, without requiring a guard on u. D 

Definition 12. A vertex is cleared if all its in-edges and out-edges are cleared, 
partially cleared if all its in-cdges are cleared and at least one of its out-edges 
is contaminated, contaminated if at least one of its in-edges and all of its 
out-edges are contaminated and no robot is guarding it, and critical otherwise. 
A contaminated vertex can be a start vertex, a concept which is introduced 
below. D 

The state of an edge e e Eg is Se{e) G {eel, eco}, where eel and eco correspond 
to "cleared" and "contaminated" respectively. Similarly, the state of a vertex 
V G Vg is Sv{v) € {vcl, vpc, vcr, vco} where vcl, vpc, vcr and vco correspond to 
"cleared" , "partially cleared" , "critical" and "contaminated" respectively. The 
state of a graph is the set of all states of its edges and vertices. 



Definition 13. A graph is cleared if all its vertices are cleared, partially 
cleared, or are guarded by a robot, it is contaminated if all vertices and edges 
are contaminated, and it is critical if it is neither cleared nor contaminated. D 

4.4.2 Graph Clearing Sequences 

A strategy defines a set of moves of the robots depending on the observations 
about the targets, which are obtained by querying the state of the graph, e.g. 
using sensors, see Section 14.1.31 We define strategies for the cops that assume 
that a central authority can control the movement of the robots. A list of 
robots *H that are available to move is maintained as well as an auxiliary list of 
cops © that keeps track of the guarding robots. Given that there are m robots 
{Rq,Ri, . . . ,Rm-i}, we always have IHU © = {Ro,Ri, . . . ,Rm-i}- 



Definition 14. Given a graph G — (Vg, Eg) and sufficiently many cops in 9\, a 
clearing move g is defined as a sequence of movements of robots that satisfies 
the following procedure: 

(51) itm^d} then select i? G 9^ and remove R from m 
else select a guarding robot R from 25 

Place i? as a guard on a contaminated vertex v G Vg and put i? in 25 

(52) for each out-edge {v,u) G Eg of v do 
(S2.1) itm^d} then select i?' G IH 
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else select a guarding robot R' from © and remove R' from 25 
Place R' on v 
(S2.2) Slide R' from m to w along {v,u). This cleans the edge {v,u) 

(53) while there is a partially cleared vertex p E Vg do 

(53.1) if «n 7^ then select R" G m 

else select a guarding robot R" E © and remove R" from © 
Place R" on p 

(53. 2) for each contaminated out-edge (p, q) € Eq of v do 

(S3. 2.1) Slide R" from p to g along {p, q). This dears the edge {v, u) 

(54) if V is cleared then place R back into IH 

This procedure is satisfied by a sequence of robot moves if the statements are 
completed sequentially, i.e. (SI) precedes (S2), (S2) precedes (S3), (S2.1) pre- 
cedes (S2.2) and so on. Note that the dots indicate a hierarchy, so (S2) is 
completed only if (S2.1) and (S2.2) are. The contaminated vertex v € Vg se- 
lected in (SI) is called the start vertex of the clearing move. D 

The procedure presented in the above definition does not deterministically spec- 
ify the moves of each robot at every time. The sources of nondeterminism are 
the following: 

• There is no specific order according to which robot should be chosen from 
$nin(Sl), (S2.1) or (S3.1). 



• 



There is no specific order according to which the guarding robot should 
be chosen from © in (SI), (S2.1) or (S3.1). 



• Any contaminated vertex may be chosen in (SI). 

The partially cleared vertices may be chosen in any order in (S3). 



• 



• Robots that are in $H or not in ©, and not sliding down an edge in (S2.2) 
or (S3. 2.1) may move around on the graph freely. 

• The order in which the edges are cleared on the sliding moves is not 
specified in (S2) and (S3. 2). 

• Only the order of necessary moves is specified, but there could be an 
arbitrary number of actions interleaved into the given sequence that do 
not violate the procedure (i.e. guards may not move). 

While a clearing move does not completely specify all robot moves, it completely 
specifies the change in the state of the graph, depending only on the choice of 
the start vertex v in (SI) and the choice of the robots R, R' and R" in (SI), 
(S2.1) and (S3.1) respectively. We adopt the convention that © acts like a first 
in first out (FIFO) queue so that the robot that was first selected as guard will 
be the first robot to be selected to move away from the vertex it is guarding. 
The effect of a sequence of clearing moves gagi . ■ . gn on the state of the graph 
is therefore uniquely specified by the start vertices of the clearing moves. 



Definition 15. A graph clearing sequence (GCS) for a graph G = (Vg, Eg) 
is a sequence of clearing moves F ~ gogi . . ■ gi such that at the end of the clearing 
move gi the graph is cleared. D 
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recontaminate = True 
while recontaminate do 
recontaminate = False 
for each vertex v G Vg do 

if no guarding robot on v and v cleared or contaminated then 
for each out-edge e = {v, u) £ Eg of v do 
contaminate e 
recontaminate = True 

Table 4.2: Procedure ensuring recontamination is propagated appropriately. 



A graph is initialized with all its edges and vertices being contaminated. Since 
we are only considering strongly connected graphs, there can be no partially 
cleared vertices initially if all edges are contaminated. The winning strategies 
then consist of sequences of clearing moves in which the robots move together 
to clear the graph. 

Theorem 1 ([92], Theorem 3.4). Given a contaminated graph G = {Vg,Eg) 
with cop number c{G) and at least c{G) cops in CH, there exists a GCS T for 
G. D 

When a guarding robot moves away from a critical vertex (i.e. a vertex with 
some cleared out-edges), there is the possibility of recontamination [52]. An edge 
e = (m, v) e Vg is recontaminated if it has been previously cleared but the 
vertex u is no longer guarded, cleared or partially cleared. The recontamination 
of an edge can cause vertices to change their state, and thus further edges to 
change their state, possibly causing a cascade of recontaminations in the graph. 
The state of the graph can be updated using the procedure in Table 14.21 

This procedure is used in the implementation of the global storage, cf. Section 14.5.21 
It can be shown that no recontaminations are necessary to clear a contaminated 
graph G with no less than c{G) robots: 

Theorem 2 ([52l, Theorem 2). Given a contaminated graph G = {Vg,Eg) 
with cop number c{G), at least c{G) robots in 5H and a GCS F of G, the set d\ 
will always be nonempty at steps (SI), (S2.1) and (S3.1) of any clearing move in 
r. That is, no guarding robot ever has to be removed and no recontaminations 
occur. n 

Theorem 3. Given a graph G — {Vg, Eg), c{G) robots in IH, and a GCS F for 
G, the graph is cleared by F independently of the initial state of G. 

Proof sketch. Denote G and 9^ at the beginning of F by G and Di respec- 
tivelyO Let be the set of the guarding robots at the beginning of F (some 
robots must be guarding, otherwise the graph must be cleared and Theorem 1 
yields the result). 



= Of course, c(G) = c(G). 
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When executing F on G, at steps (SI), (S2.1) and (S3.1), the robots in & wiU 
be chosen before the robots that have been removed previously from 9i in step 
(SI). On using the guarding robots from ©, recontamination may happen. By 
Theorem 2, during the execution of F, no guarding robots other than those 
in are required in steps (SI), (S2.1) or (S3.1). Therefore, recontamination 
never affects edges that have been cleared during the execution of F in steps 
(S2.2) and (S3. 2.1) and so F clears G independently of the initial state of G. D 

Corollary 1. Given a contaminated graph G — {Vg,Eg), c{G) robots in fH, 
a GCS F for G, and a finite sequence of clearing moves F' — gagi . . . g-n, the 
concatenation F'F is also a GCS for G. 

Proof. Let G and $H be G and $H at the end of F' respectively. At the end of 
F', G is either contaminated, critical or cleared, and \D\\ < c{G). The result 
follows from Theorem 3. D 

Corollary 1 states that the set of graph clearing sequences is closed under pre- 
fixing with clearing moves. When developing a globally coordinated winning 
strategy for the robots, it is therefore sufficient to ensure that the sequence of 
robot moves it entails eventually ends in a GCS. As mentioned above, it suffices 
to specify the order of starting vertices of the clearing moves. Thus, a winning 
strategy can be defined by a function from the state of the graph to the next 
starting vertex. 

Since we are ultimately interested in finding a locally coordinated winning strat- 
egy, the choice of the next start vertex should not depend on the entire state of 
the graph, because in a real implementation this information is not available to 
the robots without a central authority to coordinate them. Therefore, let Vq be 
the set of vertices for which a robot can observe the state before the i**^ clearing 
move. It is defined to be Vq for i = and for i < by 

V ^VQ^3e = {p,q) (^ Eg .Se{e) ^ec\ h{p^v\/ q = v\/ 3/ = (r, s) (^ Eq ■ 
{r = V A {p = sy q = s) y .s = V A {p = r y q = r))). 

That is, before the i^^ clearing move gi in F, a robot can observe the state of a 
vertex u e Vg iff w is the destination or source of an edge / that goes to a vertex 
u G Vg which itself is the destination or source of a cleared edge e. Hence, the 
robots have a limited visibility radius of the graph state (while still only being 
able to sense a target in the same cell). 

Definition 16. Let Eq be the set of cleared edges before the i^^ clearing move 
gi in F and (Eq) the graph induced by the edges in Eq. Let Cq C Vq be the set 
of critical or contaminated vertices in Vq that have at least one contaminated 
in-edge. D 

Definition 17. Let fj,i be the minimum number of contaminated in-edges of any 
vertex v in Cq if Cq is nonempty, and let /ij = oo otherwise. A vertex v € Vq 
is a /Xi-clear-candidate if it has exactly /ii contaminated in-edges before the 
i^^ clearing move gi in F. 

D 
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Definition 18. Let i/i be the maximum number of contaminated out-edges to 
/Lti-clear-candidates of any vertex in Vg. if /j,i < oo, and let Vi = —oo otherwise. 
A vertex is a r/j-start-candidate if it has exactly Vi out-edges to /Xi-clear- 
candidate vertices before the z*'' clearing move g^ in F. 

n 

The start vertex w* G Vq of the «*^ clearing move gi in F is selected according 
to the following heuristics, denoted by T-L. The six criteria are listed in order of 
decreasing priority: 

(HI) The vertex v"^ is contaminated. 

(H2) The graph {Eq'^) must be connected (but not necessarily strongly con- 
nected) . 

(H3) If it exists, select a t-i-start-candidate vertex u* e Vq which is not a fii- 
clear-candidate. 

(H4) Otherwise, if it exists, select a i/i-start-candidate vertex w* G Vq which is 
also a fii clear-candidate. 

(H5) Select the vertex with the minimum number of in-edges. 

(H6) Select the vertex with the maximum number of out-edges. 

Note that even after (H6) there still might be several possibilities of choosing 
w* in which case the start vertex is chosen nondeterministically. 



4.4.3 Evaluation of the Strategy 

With these heuristics, the i^^ start vertex is selected from the contaminated 
vertices in Vq. This is a local decision in order to solve the global problem 
of finding the best starting vertex. This requires to make assumptions on the 
graph that permit the local heuristics to always lead to a global solution, i.e. 
choosing the start vertices according to the local heuristics successfully clears 
the graph G with exactly c{G) robotsO 

When choosing the start vertices according to the above heuristics H, it is 
hoped that a GCS results. However, this is not true for all graphs. One pos- 
sible counterexample is the graph in Figure l473l This is a planar graph with 
just five vertices, but still the heuristics do not necessarily produce a GCS. A 
GCS would arise from choosing to guard vi and Vi (in any order). However, 
the heuristics may choose from any of the following sequences of start vertices: 
W2foW3 or W2foi'4 or -y4Wi. However, the former two require four robots, while 
the cop number of the graph is just three. 

The heuristics would be easy to fix for this graph by adding another criterion 

(H7) In a tie, sum up the contaminated out-edges of the destinations of each 
vertex and choose the vertex with the maximum such number. 



°The same principle is used when optimizing convex functions using local decisions, since 
the global assumption of convexity means that any local optimum is a global optimum. 
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Figure 4.3: An example graph with five vertices for which the heuristics fail. Its cop 
number is three, but with the heuristics "H, four cops might be required (although not 
in all cases.) 

Vertices Samples Counterexamples 



5 


1000 


1 


6 


1000 


4 


7 


1000 


11 


8 


1000 


16 


9 


1000 


23 


10 


1000 


42 



Table 4.3: Counterexamples to the heuristics Ti. Random graphs generated according 
to Section I4T2I 

Even if this would give rise to a GCS for this particular graph, it does not how- 
ever solve the general problem: We try to find a simple solution to a provably 
hard problem, i.e. solving a global problem using only local information. 



In general, the larger the graphs get, the more likely it is to encounter graphs 
that cannot be cleared using the heuristics with just c{G) robots. Table IXSl 
presents the results of simulations for a number of small graphs. For various 
counts of vertices, random graphs have been generated and the number of in- 
stances in which H does not result in a GCS are listed as counterexamples. The 
larger the graphs, the more likely it is for H to not yield a GCS. In the worst 
case of the explored examples in Table W^ even c{G) + 4 robots are required. 



Reformulation as Optimization Problem 

Finding the minimum number of robots required to clear a graph can be formu- 
lated as an optimization problem. In order to evaluate the cop number of a graph 
with n vertices, we consider an objective function cn„(G', 5) : &„ x Vq — > N 
from graphs G G 6„ and sequences of starting vertices 5 € Vq to the number 
of robots required to clear the graph when placing them on the start vertices 
S in (SI) of the clearing movesjj The function cn„ is potentially a very com- 
plicated function, and, as the results presented in Section 14.3.21 show, requires 
exponential time to compute in the number of vertices n. 



^Recall from dcfimtion l4.1.1l that Sn is the set of strongly connected graphs with n vertices 
and from Definition 4 that Vq is the set of nonempty sequences over Vg . 
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We now minimize cn„ over the sequences of starting vertices for some given 
graph G G ©„. When ah sequences of starting vertices are feasible, then the 
minimum will be equal to the cop number c(G) by definition: 

^1 : c{G)= min cn„(G,(5). 

sev+ 

Encoding the graph G as an adjacency matrix Adj(G') and 6 as a vector may 
yield a combinatorial optimization problem. Solving this is of course NP- 
complete, corresponding to the complexity of computing the cop number. 

Now, the heuristics can be interpreted as constraints on the set of feasible se- 
quences of starting vertices. Here we denote a heuristics simply by a proposi- 
tional function h{G, 6) : 6„ x Vq — > B that is true iff the S satisfies the heuristics 
h in the graph G. Finding the number of robots under a heuristics h can thus 
be reformulated as the optimization problem 

^2 '■ rnin cn„(G', 5) 

sev+ 

s.t. h{G, 5) = True. 

Showing whether a heuristics h is optimal, in the sense that it always chooses 
the best start vertex so that only c{G) cops are required to clear the graph is 
equivalent to proving that for all graphs G, the solutions to the optimization 
problems ^i and ^2 yield the same value. This can be written as: 

/i optimal <=> VG e ©„ . min^gy+ cn„(G,(5)= iTniig^y+ cn„(G, (5) 

s.t. h{G, 5) = True *■ ' ' 



Table 1331 clearly shows that the heuristics Ti. we developed is not optimal. How- 
ever, even if we could develop an optimal strategy, verifying this using (14. 4p 
would be a nontrivial task. 



4.5 Locally Coordinated Strategies 

So far we assumed that a central coordinating authority exists that can directly 
control the robots. However, we are interested in developing a locally coordi- 
nated winning strategy. Several questions must be answered: How to adapt the 
globally coordinated winning strategy to a locally coordinated one? How is au- 
thority negotiated between the robots, i.e. how do the robots coordinate? Where 
is the information about the state of the edges and vertices of the graph stored 
and how is it accessed or observed by sensors? This section is dedicated to an- 
swering these questions, and a complete specification is presented in Section [ 



4.5.1 Negotiations 

Given a graph G and its cop number c(G), we would like to find c{G) strategies, 
one for each robot, that together implement a winning strategy for G. No cen- 
tral authority is used, and so the robots must somehow cooperate in order to 
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eventually find the targets. The required communication protocol has already 
been presented in Section 13.2.21 

Coordinating their movements on the graph restricts the authority each indi- 
vidual robot has. For example, a guarding robot may not move from a vertex v 
while another robot is engaged in sliding down the out-edges of w. This requires 
the robots to be able to negotiate for authority over each other, so that one 
robot can, at least temporarily, control the other. 

Instead of implementing sophisticated negotiation algorithms in the specifica- 
tion, we fix the structure of authority. Thus, each robot has a master and a 
slave, resulting in a circular structure of authority. Indeed this is necessary 
when recontamination occurs and the robot that was the first guarding robot 
in the GCS is told to move by its master. 

This results in symmetrical specifications of the robots, where each robot pro- 
vides the same services to its master and may expect the same services from its 
slave. We therefore develop only one local specification ip and merely change the 
names of the variables specific to a robot. In practice, ip is synthesized once and 
the architecture ensures that the communication channels are set up correctly, 
see Section [5.2. II 

Thus, negotiation is decided at specification time and no longer has to be taken 
account in the specification. Communication is then merely used to transfer the 
commands from masters to slaves. The data, i.e. the state of the graph, can 
directly be obtained from the global storage discussed next. 



4.5.2 Global Storage 

Our implementation of the locally coordinated strategy for the cops and robbers 
game does not require the robots to have knowledge about the entire state of 
the graph. Instead, the robots are only provided with the information that is 
immediately required to form a local decision about the next move. This is 
achieved by storing the entire state of the graph in a data structure that can be 
accessed by all robots, but only provides local information to each robot. 

Keeping the state outside of the searchers is current practice in SAR and is 
not a new idea. For example, the United Nations INSARAG marking system 
defines a set of shapes and letter used to mark a building's status to aid the 
SAR operationslfl Similar techniques could be implemented for the SAR robots, 
but we only consider the abstraction to the graph state introduced above. 

In order to formally state a specification of a distributed solution, we must 
define how to access the global state. A robot will only ever have access to 
the state of the vertex it is currently on. We thus include the system variable 
cstj € {cl, pc, cr, sv} in the system variables of robot Rj, indicating the current 



'INSARAG Guidelines and Methodology, United Nations Office for the Goordina- 



tion of Humanitarian Affairs, Jan 2011, http : //ochajie t . unocha. org/p/Documents/IHSARAG 
|'/.20Guid6lin6s'/.202011-Latest . pdf , accessed 03. Nov 2011 
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state of the vertex the robot is on. From the point of view of the robot this acts 
Hke a sensor that reads the relevant aspect of the environment. 

The variable cstj takes the value sv if Rj is on a start vertex and (SI) is 
being executed. In (SI), Rj is placed on a contaminated vertex v, for which 
Sv{v) — vco. However, Rj may only choose a start vertex according to the 
heuristics "H. Whether a contaminated vertex is a start vertex is indicated to 
the robot by the global storage. Thus, if Sv{v) = vco, but v is not a start vertex, 
then cstj = cr from the point of view of the robot Rj if it is on v. However, if 
w is a starting vertex and Rj is on v, then cstj — sv. Otherwise, cstj takes the 
values cl, pc and cr if Sv{v) = vcl, Sy{v) — vpc and Sv{v) = vcr respectively. 
This will later be used in the specification of the controllers in Section 15.2.21 

In an implementation, it has to be ensured that the robot indeed gets the cur- 
rent state of the vertex on which it is. This requires in particular that the state 
of the graph is updated appropriately. Initially, all edges of the graph are con- 
taminated. The state of the vertices only changes with the state of the edges 
to which they are connected, and the state of the edges changes depending on 
the movement of the robots on the graph. Thus, the global state of the graph 
changes only when a robot slides down an edge in steps (S2.2) or (S3. 2.1) or 
the graph is recontaminated. In the latter case the procedure in Table 14.21 is 
executed. 

Keeping the state of the graph outside the robots has several advantages: The 
robots do not need to communicate the local information they have to each 
other, reducing the need for system and environment variables for communica- 
tion. Furthermore, the state space of the robots decreases significantly by only 
querying the immediately relevant local information of the graph. Note that 
the state of a graph with n = \Va\ vertices is uniquely defined by the states of 
its edges, giving rise to 0(2" ) configurations in dense graphs. 



4.5.3 Multi-Stage Specification 

The local specifications must ensure that all robots together execute a sequence 
of movements that satisfies a GCS, i.e. a sequence of clearing moves. Thus a 
robot may be in one of four modes corresponding to the possible movements 
necessary to implement a clearing move. The robot Rj with index j therefore 
has a system variable Mj e {cs, gu, sp, si} keeping track of the mode of the 
robot. If Mj = cs, the robot is searching for a (contaminated) starting vertex 
in (SI). If Mj — gu, the robot is guarding a vertex in (SI). If Mj — sp, the 
robot is searching a partially cleared vertex in (S3). And if Mj = si, the robot 
is sliding down the out-edges of a vertex in (S2.2) or (S3. 2.1). 

All robots except one are initialized to guard some arbitrary vertex in the graph, 
i.e. they are in mode M = gu. The remaining robot is initialized on some arbi- 
trary vertex but is searching for a starting vertex, i.e. it is in mode M = cs. For 
reference, a summary of the environment and system variables of the robots is 
given in Table 15.81 and Table 15.91 respectively. 
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Searching for Start Vertices: M = cs 

A robot Rj in mode Mj = cs searches for the contaminated vertex that is to 
be the next start vertex in the sequence of clearing moves T that constitutes 
a GCS for the graph G. The robot searches ah vertices, querying their states 
until a start vertex is found, indicated by cstj = sv. This search is done in a 
circular fashion as outlined in Section 14.2.21 Using a circular search, the robot 
knows when all vertices have been visited and no contaminated vertex is in the 
graph. In this case, the graph is known to be cleared already. 

If a contaminated vertex v is found that matches the six criteria in the heuris- 
tics H, it is selected as start vertex. Consequently, the robot enters guard mode 
Mj = gu and stays at v until called by its master to move away. On entering 
guard mode, the robot's slave, with index j', is instructed to also move to v and 
start sliding down the out-edges of v to clear them. Thus the slave is forced to 
enter the search for a partially cleared vertex with Mji = sp. 



Guarding: M = gu 

A robot Rj in mode Mj = gu is guarding the vertex v on which it is currently 
positioned. Note that v must necessarily be a start vertex. Rj thus stays at v 
until instructed by its master Rjh to move away. The only way the master Rjh 
can force robot Rj to leave i;, is to be guarding a vertex w itself and to then 
instruct robot Rj to enter the clearing mode Mj — si and clear all out-edges of 
the vertex w guarded by the master. 



Searching for Partially Cleared Vertices: M = sp 

This mode is very similar to searching for start vertices. However the difference 
is that the robot Rj reacts to finding a partially cleared vertex v by directly 
entering the clearing mode Mj = si. A partially cleared vertex does not need 
to be guarded, and thus in this case the robot that finds such a vertex does not 
need to instruct its slave to help clearing the out-edges of v. 



Clearing: AI ~ si 

In the clearing mode Mj = si, robot Rj is using sliding moves to clear the out- 
edges of a partially cleared or guarded vertex Vi . The vertex Vi is stored in the 
robot's system variable store j = i, which is set on entering the clearing mode. 
The out-edges of v are cleared one at a time, which is specified in the guarantees 
of the robot's specification. Since the order of edges to be cleared by sliding is 
arbitrary in the definition of a clearing move (see the discussion of sources of 
nondeterminism below the definition), it is perfectly admissible to fix the order 
at specification time. 

To keep track of which out-edges of a vertex have already been cleared, the 
robot keeps a system variable Cj, which is a counter that is initialized to zero 
when the clearing mode is entered, in addition to setting storej to the index i of 
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the vertex Vi. Whenever the robot shdes down an out-edge of Vi, Cj is increased 
by one. This is guaranteed by properties similar to the following: 

/\ /\ D{store,^iAc,^jAXi^O{XrAc,=j+l)), 

ie[0,n)7e[0,7i) 

where 7^ is the number of out-edges of the vertex i and wly is the (unique) vertex 
such that there is an edge e from i to w* and e is the 7"^ out-edge to be cleared 
by the robot. 

After clearing an edge, the robot has to return to the stored vertex in storcj 
again, which is guaranteed by properties similar to 

□ ( V (store, =zA V (c, =7+lAX;^J)^0 \J {storCj = i A Xfj). 

i£[0,n) 7e[0,7i) ie[0,n) 

The full specifications that follow the ideas developed in this section are given 
in Section [5I2I 
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Chapter 5 

Implementations 



In this chapter, we present two implementations of controllers for SAR robots, 
one for stationary target search in an USAR application, and the other for mov- 
ing target search in a WiSAR application. In the stationary target search, a 
central authority, called the "allocator" is responsible for dispatching the robots 
to the vertices in the graph where a target needs to be rescued. In the moving 
target search, a distributed solution is adopted, where the authority structure 
among the robots is already negotiated in advance, cf. Section 14.5.11 



5.1 SAR of Stationary Target 

In USAR, the targets are mostly considered stationary. We develop specifica- 
tions to build controllers for a team of robots that is managed by a central 
allocator. The goal is to find all targets in the affected area and rescue them. 
A robot that is at the location of a target may engage with it by performing a 
rescue task like providing medical support. In this scenario, we will consider a 
target to be rescued if a = 2 robots have engaged with it for a sufficient amount 
of time. 

The allocator is responsible for gathering information about the targets' status 
and location, and coordinating the action of the robots by dispatching them to 
the location of a target. If a robot is not dispatched, it may move around freely. 
The topology is represented as a graph, which is explained in Section 14.1.11 It is 
optimistically assumed that the entire graph is known to the robots at synthesis 
time and that it does not change during the SAR task. 

When the allocator dispatches a robot to a vertex, it merely asserts the index of 
a target's vertex on a transmission variable to the respective robot. The robot 
is then expected to move to this vertex on its own account, so the allocator does 
not need to know the topology. The allocator knows about a target's needs 
by receiving a message, or a "fiag" associated with the location of the target. 
Targets will be assumed to be stationary since an injured or trapped person will 
not move. 
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Communication between the allocator and the robots is assumed to be layered 
on top of some reliable wireless protocol. Delivery of data is guaranteed even- 
tually in finite time, messages are not corrupted, no reordering takes place, no 
messages get lost — comparable to a data-layer protocol. Thus the communi- 
cation is based on the four-phase handshake protocol developed in Section 13.2.31 



5.1.1 Architecture 

We synthesize the controllers for a set of robots and the central allocator. The 
asynchronous composition of the reactive systems resulting from the synthesis 
must satisfy the global specification of rescuing each flagged target, see Section 14.2.11 

In order to be able to simulate the reactive systems, it is necessary to close 
them as explained in Section 12.2.11 This is done by also synthesizing a reactive 
system for each vertex or "cell" in the topology. These reactive systems con- 
trol the flags according to the environment assumptions of the allocator, which 
gathers the information about the targets. The complete architecture is shown 
in Figure 15.11 and the individual parts are explained below. 



Allocator and Queues 

At the heart of the architecture is the allocator, denoted by AMM. It is con- 
nected to the robots, {Ro,Ri, . . . ,Rm-i}- The cells are also included in the 
figure to show how the closed-loop system would be controlled. They are shown 
asFDS's{Co,Ci,...,C„_i}. 

The allocator is informed about whether a target needs to be rescued by the 
boolean flags /o, /i, . . . , fn-i, each associated with one cell. Similarly, the al- 
locator knows about which robots are ready by receiving the boolean variables 
ro, ri, . . . , r„i-i, each associated with one robot. If a robot is ready and a ver- 
tex has been flagged, the allocator must dispatch a robot to the vertex that has 
been flagged for the longest period of time. 

If there are n vertices and m robots, the allocator would need at least 2"+'" 
states to account for the n flags and m ready signals of the robots. However, in 
order to reduce the allocator's state space, two FIFO queues FIFOf and FIFOr 
are implemented as separate components that maintain which target and robot 
has been waiting for the longest period of time respectively. Thus the envi- 
ronment variables of FIFOf are the flags /o, /i, . . . , /n-i and the environment 
variables of FIFOr are the ready signals ro, ri, . . . , rm-i. 

The allocator receives a flag-index F G [e, n) from FIFOf, and a robot-index 
R G [e, m) from FIFOr indicating which robot may be dispatched to which 
cell. If FIFOf holds fi at its head, then it offers F = i to the allocator, and 
symmetrically if FIFOr holds rj at its head, then it offers R ^ j. Moreover, 
the allocator may request the next flag index from FIFOf by sending a dequeue 
signal DEQf, which is acknowledged by DEQf .ACK . The queue FIFOr does 
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not have such a dequeuing capability, since this is not required in the specifica- 
tion. 

The allocator can dispatch robots by setting the dispatch variable D <E [e, m) 
to the value in F. This indicates to the robot which is currently selected by 
R that it has to go to the vertex in D. Internally, A MM maintains a counter 
variable c G [0, a] of the number of robots that have already been dispatched to 
the cell with index F. If possible, a = 2 robots will be dispatched to a cell, but 
never more, because a is the number of robots that are required to clear the flag. 

We do not provide specifications for the queues since they are not synthesized 
in the way explained above. With n inputs a FIFO FDS would have C'(2"n!) 
states, making synthesis futile even for modest n. This number results from the 
0{n\) configurations the internal store of the queue can be in (corresponding to 
the system variables 3^) and the 0(2") configurations the boolean inputs can be 
in (corresponding to the environment variables X). Hence, we consider FIFO's 
as standard components and use a Python implementation for simulation. 



Robots 

For stationary target search, the number of robots required is only as high as 
the number of robots required to rescue a target, i.e. a. However, we may in- 
clude an arbitrary number of robots in the architecture to complete the rescue 
operation more effectively. For example, with a = 2, if there are two targets 
and four robots, the robots can be dispatched in teams of two and rescue both 
targets at the same time. We synthesize one controller that is used on all robots 
and simply rename the variables with indices to indicate which variable belongs 
to a particular robot. 

A robot Rj maintains its own position on the topology both in celllDj e [e, n) 
and in the boolean variables Xq,X;^, . . . ,X;^_]^. As explained above, the two 
representations are merely introduced for notational convenience in the specifi- 
cation. Another variable, store j G [e,«), stores the destination cell if the robot 
has been dispatched. 

The robot Rj knows that it is dispatched from the dispatch signal D sent by 
AMM, if the associated robot index R from FIFOr satisfies R = j, indicating 
that AMM sends D to Rj. However, the robot is not interested in whether 
any other robot is dispatched or not. Therefore, in order to decrease the state 
space of the robot, auxiliary environment variables do,di, . . . ,dm-i over the 
domain [e,n) are introduced, one for each robot. Robot j receives dj = i from 
the allocator if it is dispatched to vertex Vi. On reaching the vertex Vi, the 
robot checks its boolean sensor signal flagj whether there is still a target on 
this vertex. The environment variable flag^ is true iff there is a target on the 
vertex the robot is currently on. If a target is detected at the vertex to which 
the robot is dispatched (recognized by celllDj — store j A flag j = True), the 
robot asserts a boolean engage signal ej to indicate to the allocator that it has 
successfully reached the target's vertex. 
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Connectors 

The communication between the individual components in the architecture is 
shown by the arrows between the individual components. Some environment 
variables of the robots and cells are functions of the system variables of their 
peers. For example, the environment variable Ei of cell Ci is a function of the 
variables celllDj and Cj for j £ [0, m). One way to incorporate their relationship 
into the design would be to have Ei as a system variable and celllDj and Cj for 
j € [0,?Ti) as environment variables in Ci. Then the guarantee 

can be added to the specification of Q. Note that the summation interprets 
"True" as "1" and "False" as "0". While this would produce the desired result, 
it introduces many environment variables into the design of the cells. If they 
cannot be suitably restricted by assumptions in the specification, this will lead 
to a considerable increase in the number of states in each cell's FDS. 

To overcome this, these functions are implemented externally to the FDS's in 
the form of connectors. A connector is an invariant proposition of the global 
state space. It is of the form t? = 7r(z9oi ^17^2, ■ • •) where 1? is an environment 
variable of an FDS A4, called a connector variable, 'do,'di,d2, ■ ■ ■ are system 
variables of peers of A4 and tt is some proposition over ^Oi ^ij '^2, ■ • • with the 
additional condition that 'd is not a system variable of any component in the 
architecture and "i? is an environment variable only of Ai. Thus, a connector 
introduces a new variable to the global state variables. 

When proving properties over the composition of the specifications, these in- 
variants can simply be assumed to hold at all times. In a simulation, these 
invariants are ensured by calculating the values of a connector variable i9 when- 
ever it is accessed by an FDS. 

In our implementation of stationary target search, there are three types of con- 
nectors, shown as rectangles in Figure ETJ There is a connector for the engage 
signal Ei of a cell Ci that indicates how many robots are engaged on vertex i. 
This is expressed by 

^.=E,(e,AX/). (5.1) 

Another connector is for the flag signal flagj of a robot Rj that indicates whether 
the vertex i = celllDj the robot is currently on contains a target, i.e. fi = True. 
This expressed by 

flag^^y^iXiAfi). (5.2) 

The third type of connectors is for the dispatch signal dj of a robot Rj . Robot 
Rj is dispatched to the vertex i iS d = i and r = j, i.e. if the robot that is 
offered to the allocator is Rj and the allocator decides to dispatch a robot to 
the vertex i. This is expressed by 

^.4^' ''''-'.■ (5.3) 

I e, otherwise 

Note that the connectors have access to the global state, i.e. they are not re- 
stricted by the position a robot is in. However, the expressions in (|5.ip -f 
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Name 


Domain 


Description 


R 
F 

DEQf_ACK 


[e,TO) 

1 


Indicates a robot that is ready 
Indicates a vertex that is flagged 
Dequeue acknowledge signal from FIFOf 



Table 5.1: Environment variables of the aliocator, AMM. 



Name 


Domain 


Description 


DEQf 
c 
D 


1 
[e,m) 


Dequeue signal to FIFOf 

Counts how many robots have been dispatched 

Dispatch signal to robots 



Table 5.2: System variables of the allocator, AMM . 

clearly indicate that only the local state is used to calculate the connector vari- 
ables. By local state we mean that a cell can only use the values of robots on the 
corresponding vertex and a robot can only use the values of the cell on which 
it is currently. 



5.1.2 Global Specifications 

The composition of all components in Figure 15.11 has to satisfy the global spec- 
ification for stationary target search discussed in Section 14.2.11 in a form that 
corresponds to the problem setting considered here. A target on vertex i is 
indicated by the flag fi being asserted, and the goal of the allocator is the to 
get a — 2 robots to arrive at the vertex i. This can be expressed analogously 
to dll]) by 

A □(/.^o V (^f Axf)). 



ie[0,n) 



jie[0,m) 
J2e[0,m)\{ji} 



We now state the specifications of each component so that the asynchronous 
composition fulfills this global specification. This can be verified for example 
by using the Feedback Interconnection Refinement Rule in Proposition 1, but 
here we only note that the simulation yields the desired result. 

For compacter specifications, define 

stay{'K) =7r A O ""i 
raise (tt) = ^tt A Q ^: 
c/ear(7r) = tt A Q ^^: 
for any propositional formula tt. 



5.1.3 Allocator Specification 

The state variables of the allocator are shown in tables Table [sHI and Table [5 
The following specifications are for the FDS AMM in Figure [5T1 
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Assumptions 

Initially, no robot is ready, so FIFOr offers no robot and R ^ e. Moreover, 
FIFOf doesn't have a dequeue request to acknowledge, so DEQf _ACK is low: 

"Pa,! = (i? = e) a ^DEQf.ACK. 

FIFOr keeps track of the robots that are ready, and so, if available, presents a 
robot to the allocator that can be dispatched. This robot will not change unless 
the formerly presented robot has been dispatched: 

<^l2= A aiclear{R^j)^D^e). 
je[o,m) 

Once a vertex is flagged, it is not unflagged unless a robot is dispatched to this 
cell, i.e. no target can rescue itself. More precisely, the flag offered by FIFOf 
may only change if a robot is dispatched or a dequeue signal is sent to the queue: 

fXs^" A Oiclear{F = i)^ DEQfy D^e). 

iG[0,n) 

The dequeue acknowledgement stays high as long as the dequeue request stays 
high: 

ipAA = n{dear{DEQf .ACK) -^Q^DEQf). 

Guarantees 

Initially, the dequeue signal is low, the counter is zero and no robot is dispatched: 

fA.i = ^DEQf A c = A D = €. 

Once the allocator has dispatched a robot, it monitors the ready signal it receives 
from FIFOr. As long as this does not change, it does not clear the dispatch 
signal: 

^A,2= A A a{D = iAstay{R = j)^0{D = z)). 

je[0.,rn) ie[0.n) 

However, if FIFOr presents a different robot to the allocator, this means that 
the robot to which the dispatch signal has been sent is no longer ready and has 
successfully reacted to the dispatch request. Thus dispatch is cleared: 

^l3= A A n{D^iAdear{R^j)^0{D = e)). 

je[0,m) ie[0.n) 

If the allocator gets offered a flag F = i from FIFOf and a robot is offered by 
FIFOr, it may dispatch a robot to vertex i by asserting D = i. In this case the 
counter c must be increased by one: 

(^^4 = /y /y n(F ^iAD^eAc = -fAR=^e^ 0{D ^ i A c ^ -f + 1)). 
7<a ie[0,m) 
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The dispatch signal may only be asserted if the counter c is not saturated, some 
robot is ready and a cell is flagged: 

(/?i,5 = /\ a{D = eAO{D = i)^c<aAR^eAF = i). 

ie[0,m) 

If a robot is dispatched and the dispatch signal is changed, it must be reset: 
^le- A a{clear{D = {}^0(D = e)). 

ie[0.,m) 

Moreover, dispatching a robot requires the dispatch signal to be clear: 
fA,7 = A 0(raise(D = i) ^ D = e). 

ie[0,m) 

The counter may only increase by one if a robot has been dispatched: 

vXs = ai\/{c = lAOic = l+l))^ V iD = eAO{D = i))). 

7<S ie[0,n) 

Also, the counter may not decrease (unless it is reset), and it may only go up by 
one at a time. This requirement is captured by < (a+7'— 7) mod a < 1, where 
7 and 7' are the values of the counter at the current and next step respectively: 

fA,9 = A n(c = 7 A 0(c - 7') ^ False). 

7<a,7'<a 
0<(a+7'— 7)nioda<l 

This formulation forbids certain changes of the counter c. A positive formula- 
tion that ensures that c only changes in a permissible way can also be used but 
results in exactly the same synthesized FDS. 

If no robot is dispatched, the counter must not change: 

(^^,10 = /\nic^jA stay{D = e) ^ 0(c = 7))- 

The counter is only reset on a raising edge of the acknowledgement received 
from FIFOf: 

(/?A.ii = n(c = aAc = 0^ raise{DEQf_ACK)). 

Conversely, if the counter is saturated and a raising edge of the acknowledgement 
is observed, then the counter is reset: 

'Pa.12 = n(c = a a raise{DEQf.ACK) -^ 0{c = 0)). 

If enough robots have been dispatched to the vertex currently offered by FIFOf, 
then the counter c is saturated. The allocator must then ask FIFOf to offer the 
location of the next target, if available. For this purpose, the dequeue signal 
DEQf is raised if no acknowledgement is currently received: 

^A 13 =: n(c = a A -nDEQf_ACK A -^DEQf -^ Q DEQf). 
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Name 


Domain 


Description 


d, 




The vertex the robot is dispatched to 

Indicates whether the vertex the robot is on is flagged 



Table 5.3: Environment variables of the robot Rj. Note that dj and flag, are both 
provided by a connector. 



The dequeue signal may only go high if the acknowledgement is low: 

(^^^^4 = U{raise{DEQf) -^ Q^DEQf _ACK). 

Also, the dequeue signal must stay high until an acknowledgement is received 
from FIFOf: 

iPA,iB = D{clear{DEQf) -^ DEQf.ACK). 

GR[1] Specification and Communication 

The above formulae are composed into the specification of the allocator: 

qG[1,4] ^e[i,i5] 

which can be translated into a GR[1] specification. 

The communication with FIFOf over the request signal DEQf and the ac- 
knowledgement signal DEQf.ACK follows the four-phase handshake protocol 
of Section 13.2.31 The assumption (p\ 4 corresponds to III in A4s, and the guar- 
antees ip% ;^4 and ip% ;^5 correspond to VII and VIII respectively. IX is not 
required for a boolean request signal and XI is indirectly asserted by 93^ 4, v?^ 3 
and (p\ j^g, given that there are at least a robots offered by FIFOr. The property 
X is not guaranteed from the specification itself, but is required for the com- 
munication protocol to be valid. However, model checking the synthesized FDS 
of the allocator Ma 1= ^a reveals that also Ma ^ U{DEQf .ACK -^ Q DEQf). 
Thus the allocator satisfies the requirements to be a sender in the four-phase 
handshake protocol. 

The allocator communicates with a robot also using the four phase handshake 
protocol. The request signal that is sent by the allocator is a combination of 
the index R offered by FIFOr and the index of the target's vertex in D. In the 
notation of Section [3. 2. 3[ {r = i) ^ {D = i A R = j) for the request signal to 
robot Rj. The acknowledgement fronr robot Rj is the signal rj being cleared. 
However, rj is not received as an environment variable by the allocator, so the 
robot index R offered by FIFOr is used to extract this information: When R = j 
changes, then robot j has acknowledged the dispatch request. In the notation 
of Section [3.2.31 a <;4> dear{R = j). Thus t/s^ 2 ^^'^ Va 6 correspond to VIII and 
IX respectively, while X is implied by (p^ 3 and (^^ 2- 
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Name 


Domain 


Description 


rj 


B 


Indicates whether the robot is ready 


^j 


B 


Indicates whether the robot is engaged 


storcj 


[e,n) 


Stores the current target vertex 


celllDj 


[e,n) 


Stores the current position of the robot 


xi,ie [0,n) 


B 


Stores the current position of the robot 



Table 5.4: System variables of the robot Rj 



5.1.4 Robot Specification 

The environment and system variables of the robot Rj are given in tables 
Table [531 and Table EH respectively. In the following specifications, the sub- 
and superscripts with the robot's index j are omitted. 



Assumptions 

Initially, it is only known that the robot is not dispatched. This is a consequence 
of the robot also not being ready when it is started up (see guarantees): 

fki = id = e). 

The allocator must wait for the robot to become ready before it can be dis- 
patched: 

fiS/j 2 — D{clear{d ~ e) ^ r). 

If the allocator sends a dispatch signal, this must remain the same until the 
robot acknowledges this by clearing its ready signal. Then FIFOr deletes this 
robot out of its list of robots that are ready, which in turn is (possibly) received 
by the allocator which only then may clear the dispatch signal: 

fR.s = A Oiclear{d = i) ^ ^r). 

ie[0,n) 



Guarantees 

Initially, the robot is not engaged, not ready and has no target stored: 

(/?|j I = -^E A ^r A store — e. 

The robot becomes ready when no target is stored and it is not ready. From this 
time on, it will turn out that the atomic propositions r — True and store — e 
are equivalent, because the robot is ready exactly if no destination is stored: 

^^^2 = 0{^r A store ^ e^ Qr). 

If the robot receives a dispatch signal when it is ready, it fills its target storage 
with the appropriate destination: 

Vr,3 ~ A n{store ~eAd~iAr^ Q{store ~ i)). 

ie[0,n) 
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Moreover, a target may only be stored if the robot is ready. As a result of this, 
the robot must clear the ready signal r: 

^R.i^ f\ D{store = e AO{store = i) ^ r Ad = i A^Qr). 

ie[0,n) 

The target store may only be cleared to e, and only if the robot is at the target 
location and no flag is detected. Then also the robot must assert that it is 
ready: 

vIj.s = /\ D{clear{store ^i) ^ ^flag A Xi AQistore ^ cAr)). 

iG[0,n) 

When a destination is stored then the robot eventually reaches the required cell: 

ipufi = O{store 7^ e -> \J {Xi A store = i)). 

If the robot arrives at the correct cell and the flag is still up, then it engages: 

fR,7 = A n(''^ore ^i AXiA flag -> e). 

ie[0,n) 

If the robot arrives at the correct cell but the flag is already cleared, then the 
store is cleared, the robot goes back to ready and disengages: 

'PR,a^ /\ D{store = i AXiA^flag ^ 0{r A store = eA-'e)). 
The robot may only engage if it is in the correct cell and the flag is still sensed: 



f'k^Q = a{raise{e) ^ O I \/ {X^ A store = i) \ A Qflag). 

\»6[0,n) / 

Disengaging requires the target storage to be cleared. Note that this implicitly 
also includes all that is required to clear the target storage: 

f% 10 = D{clear{e) — > W clear{store = i)). 

iG[0,n) 

The robot is free to move as long as it is not engaged. 

Vrm= a n{stay{{)e)--.{X,^OX,)). 

ie[0,n) 

The allowable moves of the robot depend on the graph G on which the search 
is performed. Since G is given at specification time, the restrictions due to the 
topology are encoded as presented in Section B.l.li and the formula ipo is in- 
cluded in the robot's specification. 
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Name 


Domain 


Description 


Environment 


E^ 


[0,m] 


The number of robots engaged on this cell 


System 


u 


B 


Indicates whether the cell is flagged 



Table 5.5: Variables of the Cell d 

GR[1] Specification and Communication 

The above formulae are composed into the specification of the robot: 

ae[i,3] /3e[i4i] 

which can be translated into a GR[I] specification, see Section [3.1.41 

The robot Rj may receive dispatch signals from the allocator via the dispatch 
signal dj. It acknowledges such a request by clearing its ready signal rj. The 
allocator does not directly receive tj but only the signal R from FIFOr, which 
must be taken into account when reasoning about the correctness of the commu- 
nication protocols. Thus the acknowledgement signal is equivalent to rj — False, 
i.e. when the robot declares that it is no longer ready. Except in the initial state, 
this is also equivalent to stortj ^ e. The request signal is equivalent to dj ^ e. 
Therefore the guarantee tpfj 4 corresponds to XIV, and the combination of (^|j 3 
and (p^j^ 5 corresponds to XII. However, XV and XIII are not directly guaranteed 
by the robot but are required in Cases 4 and 5 of the proof of Proposition 3. 
XIII states that dj = e necessarily results in rj = True. However, since the 
allocator does not require the liveness assumption I, the proof of Case 5 still 
works without guaranteeing XIII as follows: 

To prove Precondition 1. we deduce II- VI from the conjuncts of the closures 
of ipg and (^|j. II and HI follow from \3{a — True) arising from the existential 
quantification of a. IV- VI similarly follow from \3(r — e). To prove Precondi- 
tion 2. we take i = False in the closure and the result follows trivially. 

XV states that raise{rj) requires dj — e. But the proof of Case 4 fails when 
omitting this guarantee. However, let us consider what would happen if the 
robot raised rj when dj ^ e. The allocator only receives R from FIFOr. If 
R — e then D must be e from (^^ 3 and (/3^ 5 , so in this case dj 7^ e is not 
possible. Thus at that point R ^ e and so a robot Rh, h ^ j is offered to the 
allocator in R. Thus when rj is raised, R does not change necessarily, since 
FIFOr offers R — h first. However, from the connector proposition for dj, when 
R ^ j then dj = e. So also in this case dj ^ e is not possible. 



5.1.5 Cell and Queue Specifications 



Each cell Ci in the architecture in Figure [5TT] has just one environment variable 
Ei, indicating the number of robots engaged on the cell, and one system variable 
fi , the flag of the cell. These variables are shown in Table 15.51 In the specifica- 
tion, we will again drop the subscripts from the variables and write just / and E. 
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Name 


Domain 


Description 


Environment 


rj,j e [0,n) 


B 


The ready signal received from robot Rj 


System 


R 


[e,n) 


The index of the robot offered to AMM 


Table 5.6: Variables of FIFOr. 




Name 


Domain 


Description 


Environment 


/„ie [0,™) 

DEQf 


1 


The flag received from cell Ci 
The dequeue request from AMM 


System 


F 
DEQf.ACK 


[e,n) 

B 


The index of the vertex offered to AMM 
The dequeue acknowledgement 



Table 5.7: Variables of FIFOf. 



A cell has to satisfy only two guarantees. The flag can only be cleared if there 
are at least a — 2 robots engaged on the cell: 

(Pc,i = 0{clear{f) -^ E>a). 

Moreover, we include a liveness property, ensuring that the cell will always be 
flagged eventually: 

In order for the specification to be realizable, we need to assume that as long as 
a cell is flagged, the number of robots that are engaged on the vertex associated 
with that cell will never decrease: 



Vc- 



A U{fhE^^^O{E>^)). 



7e[0,m) 



The FIFO queues FIFOr and FIFOf are not synthesized as FDS's due to the 
state space explosion problem, cf. Section l5. 1.1 1 Instead, a thread is imple- 
mented that guarantees certain properties to the allocator AMM . In particu- 
lar, the environment assumptions of AMM on the local system variables con- 
trolled by FIFOr and FIFOf must be satisfied. The conceptual environment 
and system variables of the two queues are shown in Table 15.61 and Table 15.71 
respectively. 

From (f\ -y, the allocator requires that initially "DEQf.ACK — False", which 
can easily be implemented in FIFOf . Also, ip"^ 4 requires the dequeue acknowl- 
edgement DEQf _ACK to only be lowered if also the dequeue request DEQf is 
false, which is similarly straightforward to implement. 

There is only one requirement on FIFOr ^ imposed by (/'as- The robot index 
R that is offered to AMM may hence only be changed if a robot is dispatched. 
Since FIFOr keeps track on which robots are ready, and robots may only lower 
their ready signals r following a dispatch D (cf. the connector (|5.3p ). this re- 
quirement is automatically met. 

Lastly, from f\^, the flag offered to the allocator may only be changed if a 
dequeue signal DEQf is received by FIFOf or a robot is dispatched. FIFOf 
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AMM, m = 2 
AMM, m = 3 
AMM, m = 4 
AMM, m = 5 
AMM, m = 6 
Robots i?j, any m 



4 5 6 7 



9 10 11 12 13 14 15 16 17 18 19 20 
Vertices, n 



Figure 5.2: States of allocator and robot for the stationary target search. The 
relation for both allocator AMM and robots Rj is quadratic in the number of vertices 



therefore only dequeues a flag either if DEQf is high, or the flag is lowered. By 
the cell's guarantee (p^ ^ and the connector (|5.ip , a flag can only be lowered if 
at least a robots are engaged on the corresponding cell. This again is only the 
case if -D 7^ e, i.e. a robot is dispatched. 



5.1.6 Synthesis 

The specifications given above were successfully synthesized using the TuLiP 
front end. Figure 15.21 shows the number of states of the allocator and the robot 
when varying the size of the topology and the number of robots available. 

The size of the state space of the robot does not depend on the number of 
robots in the architecture, but the size of the state space of both the allocator 
and the robots increases quadratically with the number of vertices in the graph 
representation of the topology. Also, the size of the state space of the allocator 
increases slightly with the number of robots. 

The time for synthesizing the controllers is also polynomial in the size of the 
topology, as would be expected: The size of the specification increases at most 
quadratically with n, the number of vertices in the graph representing the topol- 
ogy, and the synthesis time is cubic in the size of the specification. By plotting 
the synthesis time on a logarithmic scale as in Figure 15.31 shows that the com- 
plexity must be subexponential. A rough analysis yields polynomial complexity 
of sixth order in n, but this cannot be seen accurately from the available data. 



90 



5.1. SAR OF STATIONARY TARGET 



1000 



^ 100 



E 



CO 




allocator, m = 2 
allocator, m = 3 
allocator, m = 4 
allocator, m = 5 
allocator, m = 6 
robots, any m 



10 11 12 13 14 15 16 17 18 19 20 
Vertices, n 



Figure 5.3: Time to syntliesize allocator and robot for the stationary target search 
with n vertices and m robots. Note that the ordinate is logarithmic but the relation 
is polynomial. 



The timing measurements have been conducted on a 2.4 GHz Intel Core 17 CPU, 
with 4 GB of working memory. The available memory is likely to also affect the 
performance because the JTLV implementation uses the JVM Garbage Collec- 
tor. Note also that the graph presented in this section was obtained for just 
one random graph for each value of n. Other random graphs give different state 
space sizes and synthesis times, but the polynomial complexity results still hold. 



5.1.7 Discussion 

Stationary target search has been successfully simulated for various numbers of 
robots and vertices. When more than two robots are used, the allocator explic- 
itly requests a new flag to be offered by FIFOf and dispatches a robot to the 
corresponding vertex. Thus, with four and more robots several targets can be 
rescued simultaneously. 



However, as is clear from Figure [5T2l the size of the state space grows very fast 
with the size of the graph. This affects the efficiency of synthesis. The synthesis 
of the controllers for 20 vertices and 6 robots already took about 15 min, and 
much longer times are expected for larger graphs. However, space seems to be 
even a more pressing issue. Larger problems are susceptible to heap overflow 
due to unsuccessful JVM garbage collection. For example, synthesis of a con- 
troller for 16 vertices and 5 robots is not successful when only permitting 1 GB 
of working memory. 

The increase of the state space is mostly due to the added environment variables 
from the communication protocol. The assumptions on these additional envi- 
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ronment variables cannot be strengthened sufRciently to reduce the state space 
further. The communication in this specification already deviates slightly from 
the four-phase handshake protocol defined in Section 13.2.31 in order to alleviate 
this problem, as any additional signal like a boolean acknowledgement roughly 
doubles the state space. Also, beyond a certain graph size, synthesis seems im- 
practical. If this limitation cannot be overcome, then this type of specification 
seems unsuitable for practical applications. 



5.2 Moving Target Search 

In contrast to USAR, the targets in WiSAR are considered to be able to move. 
That means that the stationary target search methods are no longer sufficient, 
and we implement the distributed multi stage moving target search strategy 
developed in Section 14.5.31 



There is no central allocator, hence the specification is easier than that of sta- 
tionary target search. However, as is evident from Section [4.31 justifying that a 
given number robots with controllers synthesized from the specification reliably 
find all moving targets requires more effort than with stationary target search. 



5.2.1 Communication Structure 



As indicated in Scction [4.5.11 the robots are organized in a circular structure 
of authority and communication. A robot Rj has exactly one slave and exactly 
one master. Figure [53] shows such a cycle. The state variables of the robots are 
explained in Table [Q] and Table [Ql 



,Ro]^- 



ackini — ackouto 



ackiuQ — ackout^ 



^111,0— C'out,! 



^ Ri 



C'in.S— C'out.O 



Ci„,l=Cout 



Cin,2—Cout,; 



ackin2^ ackout I 



ackin^^ackout2 

Figure 5.4: Four robots comniunicating in the moving target search architecture. 
Note that only the local system and environment variables directly relevant for com- 
munication are shown. 



We use the standard four-phase handshake protocol introduced in Section 13.2.31 
Hence no sophisticated arguments as in the previous section on stationary tar- 
get search are required to justify the correctness of the communication protocols 
used. Also, the correctness of the composition of all synthesized components is 
a simple extension of Proposition 2 in Section 13.2.31 
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Name 


Domain 


Description 


ackirij 

CStj 


[e,n) 

1 

{cl,pc,cr,sv} 


Vertex the robot is sent to by its master 
Acknowledgement received from its slave 
State of the vertex on which the robot is 



Table 5.8: Environment Variables of Robot _R, 



Name 


Domain 


Description 


M, 


{gu, cs, sp, si} 


Mode of the robot 


storcj 


[e,n) 


Vertex stored for the clearing mode 


celllDj 


[0,n) 


Current position of the robot 


X^ie [0,n) 


1 


True if robot R.j is in position i 


Cj 


[^7 TmaxJ 


Counter in clearing mode 


cntj 


[o,H) 


Counter in search modes 


mcntj 


[o,bl) 


Maximum counter value in search modes 


ackoutj 


1 


Acknowledgement sent to master 


^out j' 


[e,n) 


Vertex to send the robot's slave to 



Table 5.9: System Variables of Robot Rj 



5.2.2 Robot Specifications 

Similar to the stationary target search, the global specification must state that 
any target is eventually found on the given topology. Since the search strategies 
developed in Section 1431 ensure that the graph is cleared, this global require- 
ment is necessarily satisfied, given that the architecture contains sufficiently 
many robots. We therefore only state the specifications that are synthesized 
into robots implementing a winning strategy for the cops. It is then easy to 
extend this to include sensors to detect targets and react appropriately (e.g. by 
engaging). 



In the following specifications, the subscripts and superscripts indicating the 
index of the robot are omitted for notational convenience. 



Guarantees: Topology 

Similar to the stationary target search, the allowable moves of the robot have 
to be defined in the guarantee part of the specification. The restrictions due 
to the topology are encoded as presented in Section H.l.Il and the formula ^q 
encoding the topology is included in the robot's specification. 

Note that the targets are restricted to move on the same topology. However, 
since they are assumed to be able to move with infinite speed, and the graph is 
strongly connected, the robot cannot assume any restriction on the movement 
of the targets. 
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Guarantees: Guarding Mode 

In the guarding mode M — gu, the robot has to stay at the current vertex unless 
a command from its master is received via Cin'. 

flj^i = /\ n(Af = gu A Cin = e A X, -^ 0{X, A M = gu)). 

ie[0,n) 

However, if a command is received, then the clearing mode M = si has to be 
entered, setting up the store and counter appropriately: 

'^M.2 == A ^(^'^ = gu A Ci„ == i -^ 0{M =: si A store ^ i A c ^ e)). 

iG[0,n) 

If the guarding mode is entered, then the robot's slave is instructed to clear all 
out-edges of the current vertex Vi by asserting the index i on Cout — *• However, 
if the guarding mode is entered because the counter c is saturated, this means 
that no vertex was found in M = cs or M = sp. In this case we know that the 
graph is cleared and so Cout stays at e. 



^M,3= A A □(M = csAO(M = gu)AO(^»)A 

ie[0,n)7G[0,|p|) 

cnt — J A mcnt 7^ 7 ^- 0(C'out = *))• 

Guarantees: Searching Modes 

The searching modes M = cs and M = sp can be specified together, as they 
differ only slightly by the state of the vertex the robot is searching for and the 
mode that is entered if such a vertex is encountered. 

First, when entering a searching mode, the counters must be initialized correctly: 

fli.i^ A 0{Xi A {raise {M ^ cs)\/ raise {M = sp)) 

ie[0,n) 

— > Q){cnt = 7i A mcnt — nextval{-^i) A Xi)), 

where 7^ is the index of the first occurrence of the vertex Vi in the path p. Note 
that nextval{'^) = (7 + 1 + \p\) mod \p\ as defined in Section 14.2.11 before (|4.2p . 



The robot moves along the path p one vertex at a time, making sure that the 
counter cnt increases at every transition: 

^%i,5 ^ A ^(-^pii) ^ "^"^ = 7 A mcnt 7^ 7 A 

7e[o,|p|) 

{{M = cs A Oicst ^ sv)) V (M = sp A Q{cst ^ pc))) 
^ Q,{cnt = nextvali-y) A Xp(^„^^t^ai{-r))))- 

If a start vertex has been found, then enter the guarding mode M = gu: 

'fills ^ A 0{M^csAO{cst = sv)AX^^O{M^guAc^eAX,)). 

ie[0,n) 
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Similarly, if a partially cleared vertex v has been found, then enter the clearing 
mode M = si, initialized to clear the out-edges of v. 

(PM,r= A a{M = sp A Oicst = pc) A Xi 

-^ Q{M = si A c = e A store = i A X,)). 

Also, if the maximum counter value is reached in M = sp, then there is no 
partially cleared vertex and the search for a start vertex M = cs is entered: 

fM,8^ A 0{M^spAcnt^-fAmcnt^jAO{cst^pc)^0{M^cs}). 
je[o,\p\) 

Note that the values of the counters are reset to the correct values necessarily by 
the guarantee (^^ 4. Similarly, if the maximum counter value is reached in M = 
cs, then there is no contaminated (start) vertex and the graph must necessarily 
be cleared and the robot becomes dormant in guarding mode M — gu. Note 
that an additional mode can be introduced in this case that allows the robots 
to move arbitrarily on the graph, but here only the concept of moving target 
search should be introduced. The corresponding guarantee is: 

^M,9= A DiM = cs A cnt = J Anient = -/AO{cst ^sv) ^ 0{M = gu)). 
7e[o,|p|) 

Now a few guarantees are required that prevent the counters from changing 
when they should not (so called frame axioms). The counter of the position in 
the path p, cnt may only increase until it overflows, corresponding to the path 
closing in a cycle. 

(Pm^io = D{stay{M ^ cs) V stay{M ^ sp) 

— > \J {ent ^ J A Q{ent ~ nextval{j)))). 

76[0,|p|) 

Similarly, the value stored as maximum for the counter may not change: 

(/5m.ii = D{stay{M — cs) V stay{M = sp) 

— > W {mcnt — "f A Q){mcnt ~ ^y)) . 

7e[o,|p|) 

Since cnt and mcnt are only used in M = cs or M := sp, they are set to zero 
otherwise: 

Vm,12 = U{^{M = cs V M = sp) ^ cnt = A mcnt = 0). 

Two more guarantees are required to prevent the robot from leaving the search- 
ing mode if no start vertex or partially cleared vertex was encountered or the 
counter has not reached its maximum value: 

v'm 13 = U{clear{M = cs) ^ V/ {cnt = 7 A mcnt ~ j) A Qicst = sv)), 

7e[o,|p|) 

fli 14 — D{clear{M = sp) -^ W {cnt ~ ■f A nient = 7) A Qi{est — pc)). 

76[0,b|) 
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Guarantees: Clearing Mode 

The clearing mode is the most involved mode, but also the mode that is respon- 
sible for actual progress in clearing edges: no edges can be cleared by a robot 
that is not in mode M = si. 

First, on entering clearing mode, the index of a vertex is written to store so that 
the robot knows for which vertex the out-edges must be cleared. This can only 
happen when the robot is guarding and called by its master to move, or when 
the robot has found a partially cleared cell that it is now about to clear: 

'Pm,15 = A D{store = e A Q{store = «) — > 

ie[0,n) 

(Cin = iAM = gu) V (M = sp A 0{cst = pc) A Xi)). 

Also, store may only change from e if also the counter c is reset to e or alterna- 
tively if the robot enters the clearing mode from a search for a partially cleared 
vertex: 

(^M_i6 = a{clear{store = e) ^(0(c = e) A M = gu A 0{M = sl))V 

(M == sp A Oicst = pc) A 0{M = si))). 

Moreover, if .store ^ e, then it may only change to e, i.e. it is not permitted 
to immediately change from sliding down the out-edges of one vertex to sliding 
down the out-edges of another. Such a change also requires the counter c to be 
saturated, indicating that all out-edges of the vertex held in store are successfully 
cleared: 

fM,i7 = A \3{clear {store = i) ^ Q){store = e) A c = 7^ A 0(c = e))- 

Conversely, if the counter c is saturated, then the robot has successfully cleared 
all out-edges of the vertex held in store and thus enters the search for a partially 
cleared vertex: 

Vm 18 = A 0{store = z A c = 7i — > Q){store = eAc = eAM = sp)). 

The counter c is always diligently set to e when the clearing mode is entered 
(see (p^ 2e)i representing that the robot first has to move to the vertex held in 
.store. This latter requirement is expressed using the following property: 

n(store 7^ eAc = e^ \J {store ^ i A Xi)). (5.4) 

ie[0,ri) 

Note that we write n(7r -^ 0\/i(:\o n)(^^'^^^ = i A Xi)) rather than the more 
intuitively obvious Aiero n) '-^(^ ^ .store = «—><) Xi). This is because the latter 
introduces n response formulae, each of which requires a trigger variable to be 
added to the system variables, which would multiply the potential number of 
states by 2". Using the former contracted response property only requires one 
trigger and thus the synthesized FDS has fewer states. 
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While the robot moves to the vertex held in store ^ the counter c must remain 
at e: 

^M,i9= A Oistore = iAc = eA^Xi^O{c = e)). 

On reaching the vertex, the robot sets the counter to zero. It also stays in the 
vertex so that the state of the robot is consistent: 

Vm,20^ a D{store = iAc = eAXi^ 0{c^OAXi)). 

Given that the robot is in the vertex held in store and the counter c has a value 
not equal to e, an out-edge can be cleared. The corresponding property has 
already been introduced in Section [4.5.31 

<Pk2i = A A a{store = iAc = -fAXi^O{X^.^Ac:^j+l)). 

ie[0,n)7G[0,7i) 

Recall that ji is the number of out-edges of the vertex i and w^i is the (unique) 
vertex such that there is an edge e from i to w^i and e is the 7*^^ edge to be 
cleared by the robot. After clearing the edge, the robot must move back to the 
vertex held in store, which is expressed by the guarantee 



D Y stores i A \/ {c ^ -f + I A X^^^) ^ () \/ {store ^ i A X.,) 

\je[0,n) 7e[0.7i) ie[0,n) 

(5.5) 
This again is a response property, which would require a trigger to be introduced. 
Instead of having both response properties (j5.4p and (|5.5p . we combine them 
into one guarantee: 

ip%i 22^ U{{store ^ eAc^ e)\J \J {store ^ i A \J (c = 7 + 1 A X^. )) -> 

'ie[0,n) 76[0,7i) 

\J {store = i A X,)). 

This is of course only possible since the right hand side of the implication — > is 
the same in both (15.411 and 



Again, the counter c must be restricted. It may only increase by one if an edge 
is cleared: 



^Ma3= A □ c = 7A0(c = 7+l)^ V istore = iAX,AOX.^.^) 
7e[o,a) y ie[o,7i) 

Also, the counter may not decrease unless it is reset. Moreover, it may only 
increase by one: 

'Pm,24:= a D{store = i^ \J mcrease(c, 71, 72,1)), 

i€[0,n) 7l£[e,7i] 

72e[e,7i] 
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where increase{c, 71, 72, *) is a formula that only holds if the counter changes by 
an admissible amount, which is defined as follows: 

c = 7iAO(c = 72) if 72 =71 + 1 

/ ■^ ; or 71 = 7,; A 72 = e 

increaselc, 7i,72,J) = < 

' or 71 = 72 

False otherwise 

The counter may only be reset to e if all out-edges have been cleared: 

^11,25 — D{raise{c = e) ^ y {store ~ i f\c = Ji))- 

If the robot is not in the clearing mode, then the counter c and store are not 
used, and they are therefore set to e: 

fM,26 = 0{M 7^ sl -^ c = e A store = e). 

Finally, the robot has to remain in the clearing mode as long as there are still 
out-edges of the vertex held in store to be cleared. 

ipli^^^ = DiM^slA^ /\ istore^iWc^j,)^OiM^s\)). 

Communication 

The robots communicate with each other using the four-phase handshake pro- 
tocol introduced in Section 13.2.31 Each robot communicates with its slave and 
its master as receiver and sender respectively, see Section [4.5.11 The sender 
specifications, i.e. for the communication of the robot as master, consist of the 
following guarantees: 

VII </?M.28 ^ DiM = guA clear{Coiit = e) — ^ -^ackin), 

VIII ^\i,29 = n(M = guA raise{Cout = e) — > ackin), 
X (^M.ao = U{M = gu A ackin -)■ 0(Cout = e)), 

and of the following assumptions: 

II ifilj^i = D{raise {ackin) — > Cout "^ e), 

III <^M 2 — D{clear {ackin) — > Cout — e)- 

Note however, that the assumption n(Cout = e -^ ()^ackin) corresponding 
to I is not included, since then the specification would not be synthesizable. 
This is because the rest of the specification implicitly includes n{Tr {ackin) -^• 
{>7r'(Cout)) for some propositional formulae tt and tt'. However, leaving out an 
assumption does not render the protocol incorrect (while leaving out a guaran- 
tee would). The guarantee IX is not necessary, since the request signal Cout is 
boolean and a specification n(Cout A O^C'out — >■ O^C'out) is redundant. The 
conjunct M = gu in the antecedents of the guarantees is necessary to ensure 
realizability since Cout must be permitted to be asserted when guarding mode 
is entered (cf. guarantee fli^^)- 
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The receiver specifications, i.e. for the communication of the robot as a slave 
consist of the following guarantees: 

XII (^M^si = n(Cin 7^ e ^ O ackout), 

XIII </'m,32 ~ □(C'in = e ^ O -^ackout), 

XIV ip%i 33 = n(razse(acA;oMt) -> Cm 7^ e), 

XV </'m34 — n{clear (ackout) -> Cjn = e), 

and of the following assumptions: 

VI fli 3 ~ n( raise (Cin = e) — > ackout), 

VII ^liA = n(cZear(Cin = e) — > ^ackout). 

Note again that the assumption n(acfcowi -> 0(Cin = e)) corresponding to V is 
not included due to problems with synthesizability. But since all guarantees are 
included, the communication protocol works as proved above in Proposition 2 
in Section 15.2.31 



Assumptions 

While the specification above is perfectly realizable, due to the large number of 
possible valuations of the environment variables (|Cin| x \ackin\ x \cst\ = 8n) it 
is beneficial to make assumptions on the environment to reduce the number of 
transitions that have to be included in the synthesized FDS (see Section I2.2.2p . 

Since the state of a vertex is only required in the searching modes M — cs and 
M = sp, we can artificially set est to some arbitrary value in these modes. Then 
the robot can make the following two assumptions on the environment: 

iPM^5 = a{M ^ cs A M ^ sp ^ Oicst = cr)), 
(flis = U{stay{M ^ cs A M ^ sp) -^ Oicst = cr)). 

Here we chose to set est — cr. Note that this has to be guaranteed by the global 
storage of the graph state, cf. Section 14.5.21 



5.2.3 Synthesis 

The full specification of the robots results is the following 

1<Q<6 l</3<346 

which can be translated into a GR[1] specification and hence synthesized with 
TLV. 

The robot specifications given above were successfully synthesized using the 
TuLiP front end. For varying numbers of vertices in the topology, ninq^ ran- 
dom graphs were generated each in order to investigate the state space size and 



^For n = 11 only four samples were calculated. 
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Figure 5.5: States of the robots for the moving target search. The mean and the 
standard deviation of nine samples are shown in bold and dashed lines respectively. 



synthesis time, plotted in Figure 153] and Figure 15761 The resulting mean and 
standard deviation are presented by bold and dashed lines respectively. 

As with the controllers for stationary target search, the size of the state space 
depends quadratically on the size of the graph n. The synthesis time for the 
moving target search controllers is polynomial as well, since the curve on the 
logarithmic plot in Figure WM is sublinear. However, for a given n the state 
space size of the controllers exceeds those in stationary target search. The same 
is true for the time they take to synthesize (cf. Figure [^21 and Figure [F3)) . 



5.2.4 Simulation 

We show a simulation of the moving target search on a small graph G with 
five vertices. The cop number is c{G) = 3, and so we use three robots. The 
specification is synthesized first and then the resulting FDS is executed in three 
different threads, corresponding to three robots on the graph with controllers 
Ai'^g, M.<g^ and TW-g-^. The communication between the robots is realized using 
a shared data structure holding the valuations of the global state variables V of 
the composite FDS A^<^ = M't^g \ M'g^ \ M<^2- 



As explained in Section [4.5.31 all robots are initialized to M = gu, except one, 
which is initialized to M = cs. Figure 5.7(a) shows the initial configuration 
on the graph. Solid edges are contaminated while dashed edges are cleared. A 
vertex is black, red, green and dashed if it is contaminated, critical, partially 
cleared or cleared, respectively. 
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Figure 5.6: Time to synthesize allocator and robot for the moving target search with 
n vertices. The mean and the standard deviation of nine samples are shown in bold 
and dashed lines respectively. Note that the ordinate is logarithmic. 



The execution of the asynchronous composition of A^%, Ai-^^ and Ai-^^ results 
in a sequence of states soSiS2 ■ ■ • \^A4'^. Significant points in this sequence are 
shown in Figure 15.71 It can be seen that the graph is successfully cleared with 
the given number of robots. The specifications do not state how the target is 
detected, in which case the moving target search would have ended with the 
target being found (if one exists). 



5.2.5 Discussion 

Again, as in the case of the stationary target search, the size of the state space 
increases quadratically with the number of vertices in the graph. However, the 
number of robots does not influence the size of the state space, since each robot 
has exactly one master and one slave and no further negotiation is required. 
Still, due to the required additional variables for communication, the synthe- 
sized FDS's are even larger than those in stationary target search. 



In the searching modes, the circular search introduced in Section 14.2.21 is used. 
This results in a rather inefficient moving target search implementation. How- 
ever, the robots only have local information, so when global properties such as 
"for all partially cleared vertices" need to be implemented in such a distributed 
way, a tradeoff between information and efficiency is introduced. Note also that 
by only using Vq, the heuristics Ti uses local information to decide on the start 
vertex. 



When a robot is guarding a vertex, it cannot move. In this specification of 
moving target search, there is always only one robot not in guarding mode un- 
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(a) sq: Initial configuration. 



(b) si: Robot Rg starts moving 





(c) sq: Robot Ro moves onto the starting (d) sg: Robot Rq realizes that V4 is a starting 
vertex v^. vertex and goes to M = gu, calling its slave 

Ri. 





(e) S24: Robot Ri goes to M = si and arrives (f) S2g. Robot Ri clears the edge from V4 to 
at V4. VQ. V4 becomes critical. 

Figure 5.7: Simulation result of moving target search on a graph with five vertices 
and three robots. 
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(g) S47: All out-edges of 1)4 are cleared. 





(h) S50: -Ri goes to M = sp to search for a 
partially cleared vertex. 




(i) Sag: Ri found D2, a partially cleared ver- (j) sgQ: All out-edges of D2 are cleared. V2 it- 
tex. self is now cleared and V3 is partially cleared. 

Ri continues looking for partially cleared ver- 
tices. 





(k) siig: Ri has finished clearing all out- (1) S121: Ri tries looking for other partially 
edges of all partially cleared vertices. cleared vertices, but will not find any. 

Figure 5.7: Simulation result of moving target search on a graph with five vertices 
and three robots. 
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(m) S136: Ri discovered no partially cleared (n) S139: Coincidentally, the vertex _Ri is on 
vertex and thus goes to M = cs to search for already is the starting vertex, so Ri enters 
the next starting vertex. guarding mode M = gu without moving. 








(o) S143: R2 is the slave of Ri and enters (p) sisg: All out-edges of iii are cleared, and 
M = si to clear the out-cdgcs of tii the graph is already cleared, but the robots 

continue moving until all edges are cleared. 



''-r 



1 R-i:gu I 












1 Ho;, 



(q) ■5183^ A.II edges are cleared after R2 has (r) S213: After R2 has unsuccessfully 
cleared no which was partially cleared in S159. searched for partially cleared vertices and an- 
R2 is still in M = sp after clearing vq. other starting vertex, it also enters M = gu. 



Figure 5.7: Simulation result of moving target search on a graph with five vertices 
and three robots. 
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less the graph is already cleared. This might seem inefficient, as only one robot 
can move. However, the guarding robots are playing an important part in the 
search; if they move, recontamination could revert the progress of previous slid- 
ing moves. 

One reason why the moving target search strategy can be implemented in such 
a way is because the global storage (cf. Section H. 5. 2|) allows the robots to not 
retain any historical knowledge of the graph state. Also, the heuristics "H is 
implemented in the global storage, so that the start vertex is offered to a robot 
Rj simply by letting cstj — sv. In a real-world implementation this has to be 
taken into account. 
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Chapter 6 

Conclusion 



In this thesis, a framework for specifying and reasoning about communicating 
and cooperating SAR robots is introduced, and the synthesis of controhers from 
their specifications is demonstrated. We further define and verify a communica- 
tion protocol, allowing reliable asynchronous transmission of data between the 
robots. 

The methods are demonstrated by successfully synthesizing and simulating con- 
trollers for robots performing centrally coordinated SAR of stationary targets, 
and for robots performing distributed search of moving targets. This demon- 
strates that it is possible to automatically generate discrete controllers for coor- 
dinated SAR operations that are mathematically proven to achieve their high- 
level goals. 

6.1 Observations 

The controllers cannot ensure bounds on the time it takes to eventually find a 
target. This is limitation inherent in the fragment of the specification language 
that we use and the synthesis method. However, fast searching is paramount, 
as with increasing time the chances of successful rescue dwindle, which is exac- 
erbated in WiSAR, where it is usually necessary to increase the search radius 
with time. 

With respect to the expected time to find a target, there is is a tradeoff between 
the accuracy and speed of effective search. These two factors are also called 
detection and coverage 31 . With greater accuracy the search takes longer 
and the probability of a SAR operation being successful decreases. In typical 
SAR operations, exhaustive search is only resorted to if other more effective 
search strategies have failed to yield useful information. 

The discrete controllers are synthesized to satisfy their specifications with math- 
ematically proven certainty. However, this requirement might be too rigorous 
for uncertain environments, compromising robustness in the case of unexpected 
scenarios or failures. For example, a change in the topology would render a 
controller unusable and cause the robot to stop operating. Also, it might be 
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sufficient to guarantee that targets are found only with very high probability, 
or almost surely, while ensuring a faster overall operation. 

With this type of controllers, the tradeoff between detection and coverage is 
completely ignored, and the search is always exhaustive. The accuracy of de- 
tection depends on the sensors being able to reliably detect targets. No such 
sensor exists, and sensors with high false-alarm rates lead to misallocating res- 
cue robots that could be used otherwise to improve coverage. 



6.2 Viability of Approach 

Two key themes limiting the versatility of the proposed methods throughout 
this thesis are the computational complexity of the synthesis methods and the 
size of the state space. It may be objected that all information required for 
the controller is already encoded in the specification, and that the synthesis is 
wasteful both in terms of time and space. A program in a procedural language 
rather than an FDS could be used instead with the same effect but with lower 
space requirements. However, for complex specifications, program validation 
can likewise be a lengthy task. 

In particular for the search strategies, algorithms have been developed that have 
proven to yield the same results as the tediously specified FDS's. It might not 
be viable to translate an existing algorithm into LTL and then synthesizing it 
back into an executable FDS. However, development of rule-based controllers 
or incrementally subjecting algorithms to more requirements can be handled 
straightforwardly with LTL specifications (as long as the specification remains 
realizable), e.g. introducing a new traffic rule when controlling an autonomous 
vehicle for urban traffic. 



6.3 Future Work 

Several improvements and extensions that are relevant for the specification and 
synthesis of controllers from LTL can be made. In SAR operations, it is of- 
ten required that there are agents designated to particular tasks, e.g. robots 
specialized for searching large areas, searching on a small scale and extracting 
victims, or providing medical relief. This heterogeneity can be exploited for 
more efficient SAR strategies [21]. Moreover, a distribution of the resources can 
be included, such as partitioning the topology among several teams of robots. 

The currently implemented search strategies are effective, but inefficient. This 
can be partially alleviated by the above improvements. Another approach would 
be to allow more robots than the cop number and implement fast search strate- 
gies that require each edge to only be traversed once by a robot [5S]. Also, 
efficient search methods that rely on probabilistic information on the environ- 
ment can be synthesized from probabilistic temporal logic specifications [3 [53] . 
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The controller specifications are small compared to the FDS's resulting from 
synthesis with TLV. It would be beneficial to exploit the compactness of a spec- 
ification and perform synthesis on-the-fly instead of generating a static FDS. 
Such dynamic approaches are already used for model checking, e.g. by synthe- 
sizing deterministic monitors [^. Dynamic synthesis is still in its infancy, but 
receding horizon, on-the-fly and compositional methods are already being de- 
veloped naiD]. 

Finally, Chung et al. 17^ state that 

"due to poor reliability and the number of possible failures, few 
multi-robot systems have been tested on the scale necessary to demon- 
strate pursuit-evasion in complex environments." 

This thesis shows that theoretically the synthesis of controllers for SAR robots 
is viable, but neither the technology of robots is yet advanced enough, nor is 
controller synthesis explored to the extent that large-scale complex SAR scenarii 
can be implemented based on the methods that we present. The small exist- 
ing sample implementations do not yet allow reliable communication between 
the robots [15]. Given the promises in robot-assisted SAR and the complexity 
reduction through synthesis, it would be a rewarding endeavor to test the pre- 
sented methods on hardware. 
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